From owner-v6ops@ops.ietf.org Mon May 9 19:45:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28393 for ; Mon, 9 May 2005 19:45:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DVHuk-000LX1-Se for v6ops-data@psg.com; Mon, 09 May 2005 23:43:54 +0000 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DVHui-000LWl-UT for v6ops@ops.ietf.org; Mon, 09 May 2005 23:43:53 +0000 Received: from [81.187.254.247] (helo=[81.187.254.247]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DVHuf-0003oL-3n; Tue, 10 May 2005 00:43:49 +0100 Message-ID: <4461296A.2080308@dial.pipex.com> Date: Wed, 10 May 2006 00:44:42 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker CC: Alain Durand , "'v6ops@ops.ietf.org '" Subject: Re: WG Last Call: draft-ietf-v6ops-natpt-to-exprmntl-00.txt References: <54277784f4166d4c478940341d31a534@cisco.com> <3b19a9cc29c540ba27fa08ca32940890@cisco.com> <3d832b567b2f3cbdc99e952a1313b04a@tycool.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_FUTURE_96_XX autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I beleive that the items inherited from IPv4 NAT are basically at the 'section' level in this document. Alain's point could be covered by adding a paragraph to the introduction which lists the section numbers which are common to any NAT-like solution. I think the list is ss 2.1, 2.2, 2.3, 2.5, 2.6, plus the basic underlying issues in ss 3.2-3.4. I also note that we missed getting a formal view from an SCTP expert. I had a few words but they didn't really resolve my issues. Regards, Elwyn Fred Baker wrote: > It would have been nice if you said this two weeks ago.. > > OK, what specifically do you want the authors to do? > > > On May 9, 2005, at 2:10 PM, Alain Durand wrote: > >> >> On May 9, 2005, at 1:21 PM, Fred Baker wrote: >> >>> On Apr 18, 2005, at 3:11 PM, fred@cisco.com wrote: >>> >>>> I believe that we are ready for a working group last call on >>>> draft-ietf-v6ops-natpt-to-exprmntl-00.txt. The proposed status is >>>> BCP. This call will end on May 6. Please finalize your comments on >>>> this draft or declare it ready for submission as-is. >>> >> >> My only comment on this draft is the way the issues are classified: >> Issues raised with NAT-PT can be categorized as follows: >> o Issues which are independent of the use of a DNS-ALG: >> o Issues which are exacerbated by the use of a DNS-ALG: >> o Issues which result from the use of a DNS-ALG: >> >> It would be useful to _also_ identified the issues that are merely >> the same as >> any v4/v4 NAT by opposition as new issues that are v6 specific. >> This would help any NAT-PT replacement candidate. >> >> - Alain. >> > From owner-v6ops@ops.ietf.org Wed Jun 1 21:23:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26533 for ; Wed, 1 Jun 2005 21:23:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdeNz-00028Z-Nt for v6ops-data@psg.com; Thu, 02 Jun 2005 01:20:39 +0000 Received: from [210.84.232.205] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdeNw-00028J-MB for v6ops@ops.ietf.org; Thu, 02 Jun 2005 01:20:37 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id B850C62AFE; Thu, 2 Jun 2005 10:50:32 +0930 (CST) Date: Thu, 2 Jun 2005 10:50:32 +0930 From: Mark Smith To: Cc: elwynd@dial.pipex.com, v6ops@ops.ietf.org Subject: Re: Please comment on new draft: draft-ietf-v6ops-security-overview-00.txt Message-Id: <20050602105032.2301340b.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <20050528193653.3229b457.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Alvaro, On Tue, 31 May 2005 17:59:08 +0200 "Alvaro Vives" wrote: > Hi Mark, > > I would like to add some comments over your comments... See below: > > > > > 2.1.11 Link-Local Addresses and Securing Neighbor Discovery > > > > "Because the link-local address can, by default, be acquired without > > external intervention or control, it allows an attacker to commence > > communication on the link without needing to acquire information > > about the address prefixes in use or communicate with any > > authorities > > on the link. This feature gives a malicious node the > > opportunity to > > mount an attack on any other node which is attached to this link; > > this vulnerability exists in addition to possible direct attacks on > > NDP." > > > > I think there is also a "non-malicious" use of link local > > addresses in the above scenario, in particular on wireless > > links, namely using the available link bandwidth to > > communicate between one or more "non-link authorised" nodes, > > rather than maliciously attacking "link-authorised" > > nodes. That is eluded to in the earlier part of the > > paragraph, possibly an explicit mention of this type of > > bandwidth theft could be useful. > > This is an interesting idea and IMO not restricted to wireless links. I > think the general idea is that link-local addresses allows communication > among hosts within a LAN and no access control could be done. For example in > a layer two infrastructure within a building two hosts could communicate > among them. > I certainly agree about it not being restricted to wireless links. The thing about wireless links is that they don't have a level of physical security protecting them i.e. building security, or required physical access to wired wall points. 802.11(a|b|g) networks are being deployed all over the place, including as open access (at layer 2) in cities, to provide subscribed Internet access. I've heard of people being willing to go so far as taking their desktop PCs in semi-public areas (were free or rather easy access to mains electricity exists) on a daily basis just to use this "free" wireless infrastructure, which surprises me. Then again, "connectivity is it's own reward." Thinking about it a bit more, this problem certainly isn't restricted to link-local addresses, as bringing up static globals or ULAs on the link would also allow bandwidth theft. Obviously this is really a layer 2 security problem in general, with IPv6 link-local's specifically making it easier exploit when using IPv6. > > > > 2.3.2 Enterprise Network Security Model for IPv6 > > > > " o Development of centralized security policy repositories and > > distribution mechanisms which, in conjunction with > > trusted hosts, > > will allow network managers to place more reliance on security > > mechanisms at the end points and allow end points to > > influence the > > behavior of perimeter firewalls." > > > > My comment is probably a bit minor. The text is abstract > > about the security mechanisms on the end-points, yet is > > specific about the idea of allowing the end points to > > influence the perimeter firewalls. I'd like to suggest either > > being a bit more specific about end point security mechanisms > > (ie. explicit "end-node firewalling"), or be a bit more > > abstract about perimeter security mechanisms. It seems to me > > that the above paragraph is somewhat implying that the idea > > of perimeter firewalls is mostly agreed upon, yet I think > > that once the end points implement firewall type security > > themselves, with a policy distribution mechanism, perimeter > > firewalls would possibly be unnecessary. This end-node > > firewalling only security model would contradict the "and > > allow end points to influence the behavior of perimeter > > firewalls" text above. > > Possibly the "and" could be changed to an "or" ? Again, this > > point is probably minor. > > > > I would suggest not to just think on end-node firewalling but in a more > complex "security tool" which will enforce the security policy distributed. > I could think in firewalling+IDS+anti-virus+anti-spam+.... > I agree, and I think that might be a good reason to not suggest specific technologies in either the end-node or network perimeter descriptions, and maybe use the term general "security mechanisms" instead. Thanks, Mark. From owner-v6ops@ops.ietf.org Mon Jun 6 07:19:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19821 for ; Mon, 6 Jun 2005 07:19:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfFa4-000CNp-Fq for v6ops-data@psg.com; Mon, 06 Jun 2005 11:15:44 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfFa2-000CNS-47 for v6ops@ops.ietf.org; Mon, 06 Jun 2005 11:15:42 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id AA4D2557B; Mon, 6 Jun 2005 13:15:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id A76905577; Mon, 6 Jun 2005 13:15:39 +0200 (CEST) Date: Mon, 6 Jun 2005 13:15:39 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Elwyn Davies Cc: v6ops@ops.ietf.org Subject: Re: Please comment on new draft: draft-ietf-v6ops-security-overview-00.txt In-Reply-To: <42850F82.7010300@dial.pipex.com> Message-ID: <20050519110311.N54691@mignon.ki.iif.hu> References: <200505131947.PAA21538@ietf.org> <42850F82.7010300@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Elwyn, Here I have some comments to draft-ietf-v6ops-security-overview-00.txt For Section 4.2: An addional reason why IPv6 by Default may brings the usability down: - At enterprises, at service providers or even at universities, in most cases the high availability is a big demand. The HA solutions nowadays are implemented only for IPv6. There lack of real IPv6 support for HSRP, VRRP (Virtual router reduncdancy protocol) [RFC3768] and even LVS (Linux Virtual Server) [LVSURL], that makes IPv6 services less robust. For Section 4.5: I would rewrite it in a following way: -----8<------------------------------------8<-------- It is very common (although questionable) practice to filter completely the ICMP messages in IPv4. This is no longer possible with IPv6. As the name that it stands for suggests, Internet Control Message Protocol for IPv6 [RFC2463] is the control and foundation protocol for the operation of IPv6, not an auxiliary protocol that can be easily omitted. Our recommendation is the following: o ICMPv6-echo-request and reply (Types 128 and 129): o You can consider enabling at least outgoing ICMPv6-echo-request and their answers, the ICMPv6-echo-reply packets to facilitate debugging. Of course, it is wise to rate limit ICMPv6 debugging packets to a certain level. o You may consider enable incoming ICMPv6-echo-request packets and their answers to your well know IPv6 service machines. You should be sure, however, that your IPv6 service machine can handle ICMPv6 requests at a certain rate. Of course, it is wise to rate limit ICMPv6 debugging packets to a certain level. o ICMPv6-destination-unreachable (Type 1): o You should consider enabling incoming ICMPv6 destination unreachable messages for debugging purpuse as an answers to outgoing IPv6 packets that have been sent out. This should be implemented with stateful packet inspection mechnanism as described in 4.5.1. o You may generate and enable outgoing ICMPv6 destination unreachable messages for all filtered packets. This is useful for debugging. It is a common practice in IPv4, to refrain from generating ICMPv6-destination-unreachable messages to hide the networking/service structure. You can apply the same rule to IPv6. If you generate ICMPv6-destination-unreachable messages, however, do it properly, setting the right reason code: no route to destination, administratively prohibited, beyond scope of source address, address unreachable, port unreachable. o ICMPv6 packet too big (Type 2): o You must enable incoming ICMPv6-packet-too-big messages as answers to outgoing IPv6 packets for the Path-MTU-discovery to operate properly. o You must generate and allow outgoing ICMPv6-packet-too-big messages properly if your MTU is different anywhere within your network from the MTU on the link between you and your provider. So be prepared, to forward ICMPv6-packet-too-big messages at the firewall. o ICMPv6-time-exceeded (Type 3): o You must/should enable incoming ICMPv6-time-exceeded messages to be able discover destination systems not reachable due to a low TTL value in the outgoing packets. This should be implemented with stateful packet inspection mechanisms to allow only answers to sent out packet packets. o You can generate and allow outgoing ICMPv6-time-exceeded messages since they are essential for proper operation of Internet. o ICMPv6-parameter-problem (Type 4): o You should consider enabling incoming ICMPv6-parameter-problem messages as answers to outgoing IPv6 packets for debugging purpose. o You must generate correct and enable outgoing ICMPv6-parameter-problem messages since they are essential for proper operation of Internet. Needs futher investigation since it can be used to scan services/networks if the attacker deliberatley sending packets with wrong headers. o ICMPv6-Neighbour-Solicitation and Neighbour-Advertisement (Type 135 and 136): o You must enable incoming and outgoing ICMPv6 Neighbour-Solicitation, Neighbour-Advertisement packets, with proper link-local addresses or solicited node multicast addresses for the Neighbour Discovery function to operate properly. o ICMPv6-Router-Solicitation and Router-Advertisement (Type 133 and 134): o If the Stateless Address Autoconfiguration function is used, you must enable outgoing ICMPv6 Router-Advertisement packets, with proper link-local addresses and multicast addresses (All node multicast addresses ff02::1). o If the Stateless Address Autoconfiguration function is used, you must enable incoming ICMPv6-Router-Solicitation packets, with proper link-local addresses and multicast addresses (All router multicast addresses ff02::2). o ICMPv6-redirect (Type 137): o You should disallow ICMPv6-router-redirect messages passing, if you have only one exit router. However, router redundancy might be implemented by router-redirect. It is important to know that redirect has link-local meaning only. o ICMPv6 MLD listener query, listener report and listener done (Type 130, 131 and 132): o You should enable incoming and outgoing ICMPv6 MLD messages, with proper link-local addresses or multicast addresses if you want to use IPv6 multicast on a bigger scope than link-local. This is required if the "internet-router-firewall-protected network" architecture is used. In this case your firewall should act as an MLD router. o ICMPv6-renumbering (Type 138): o You can disallow ICMPv6 router renumbering messages passing, since router renumbering is not widely adopted. o ICMPv6 node information query and reply (Type 139 and 140): o You may disallow ICMPv6 node information query and reply processing, since node information query/reply is not widely adopted. -----8<------------------------------------8<-------- One issue is not discussed sufficiently: 2.1.13 Adress configuration Security (only suggested section number) Common method in IPv6 to supply an address for a (default) gateway and other paramaters related to links is through Stateless Address AutoConfiguration [RFC2462], DHCPv6 [RFC3646] or static configuration. 2.1.13.1 Fake router advertisments Routers consider authoritative the information carried in router advertisements sent by other on-link routers, even though such information is not cryptographically secured (e.g., digitally signed or key-MACed or encrypted). Clients update the advertised communication parameters accordingly, without any verification. In the absence of any verification of the received information, malicious nodes may inject bogus values for optional fields of the ICMPv6 extension header, such as the advertised prefix, link layer address address of next-hop router, HopLimit, various times for addresses or MTU. However there are some protection to prevent abuse: - link MTU cannot be lower than 1280 according RFC2460 [RFC2460] - the HopLimit cannot be lower than 32? - Variauos constrains to address times A possible counter-measure that system/network administrators can query (all routers link local address) ff02::2 constantly in order to identify any "alien router" on the network segment or log router advertisement messages. These type of solution is not an ideal one because it can only warn about an anomaly, not really being able to prevent or correct it. Alternatively criptographical secured router advertisment should be implemented. The use of DHCPv6 systems may also assist in preventing such rogue configurations. 2.1.13.2 False DHCPv6 server TBD 2.1.13.3 Mismatching link-local and static parameters - maintainenance cost <- if renumbering or router change --- I hope this can improve the draft. Kindest Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Fri, 13 May 2005, Elwyn Davies wrote: > Hi. > > A new version of this draft (previously draft-savola-v6ops-security-overview) > which is now a WG draft is available. > > Please let us have any comments asap - we intend to produce another new > version incorporating any comments prior to IETF-63. > > This version incorporates a number of additional points contributed by SUZUKI > Shinsuke for the Japan IPv6 Promotional Council as well as deal of updated > wording. We are particularly interested on views of how we should proceed on > the subject of ICMPv6 filtering in firewalls. > > Thanks, > Elwyn Davies for the authors > > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations Working Group of the IETF. >> >> Title : IPv6 Transition/Co-existence Security >> Considerations > > Author(s) : E. Davies, et al. >> Filename : draft-ietf-v6ops-security-overview-00.txt >> Pages : 32 >> Date : 2005-5-13 >> The transition from a pure IPv4 network to a network where IPv4 and >> IPv6 co-exist brings a number of extra security considerations that >> need to be taken into account when deploying IPv6 and operating the >> dual-protocol network and the associated transition mechanisms. This >> document attempts to give an overview of the various issues grouped >> into three categories: >> o issues due to the IPv6 protocol itself, >> o issues due to transition mechanisms, and >> o issues due to IPv6 deployment. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the >> message. You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >> subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-v6ops-security-overview-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-v6ops-security-overview-00.txt". >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> Below is the data which will enable a MIME >> compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > From owner-v6ops@ops.ietf.org Mon Jun 6 09:02:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28271 for ; Mon, 6 Jun 2005 09:02:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfHDZ-000L6I-NU for v6ops-data@psg.com; Mon, 06 Jun 2005 13:00:37 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfHDY-000L61-7l for v6ops@ops.ietf.org; Mon, 06 Jun 2005 13:00:36 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 Jun 2005 06:00:36 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j56D0Vbw016501 for ; Mon, 6 Jun 2005 06:00:32 -0700 (PDT) From: fred@cisco.com Received: (fred@localhost) by irp-view7.cisco.com (8.11.2/CISCO.WS.1.2) id j56D0TA21968 for v6ops@ops.ietf.org; Mon, 6 Jun 2005 06:00:29 -0700 (PDT) Date: Mon, 6 Jun 2005 06:00:29 -0700 (PDT) Message-Id: <200506061300.j56D0TA21968@irp-view7.cisco.com> To: v6ops@ops.ietf.org Subject: WG Last Call draft-ietf-v6ops-bb-deployment-scenarios* X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Folks This note starts the WG Last Call for comments on "ISP IPv6 Deployment Scenarios in Broadband Access Networks", Salman Asadullah, 31-May-05, It may be found on http://www.ietf.org/internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-02.txt The document's proposed status is Informational. Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. This Last Call will end two weeks from today at Close of Business PDT. Thanks, Fred From owner-v6ops@ops.ietf.org Mon Jun 6 09:02:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28298 for ; Mon, 6 Jun 2005 09:02:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfHDk-000L7q-7p for v6ops-data@psg.com; Mon, 06 Jun 2005 13:00:48 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfHDi-000L7Y-PK for v6ops@ops.ietf.org; Mon, 06 Jun 2005 13:00:46 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Jun 2005 06:00:46 -0700 X-IronPort-AV: i="3.93,173,1115017200"; d="scan'208"; a="274817227:sNHT119146160" Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j56D0Slw018356 for ; Mon, 6 Jun 2005 06:00:39 -0700 (PDT) From: fred@cisco.com Received: (fred@localhost) by irp-view7.cisco.com (8.11.2/CISCO.WS.1.2) id j56D0WF22152 for v6ops@ops.ietf.org; Mon, 6 Jun 2005 06:00:32 -0700 (PDT) Date: Mon, 6 Jun 2005 06:00:32 -0700 (PDT) Message-Id: <200506061300.j56D0WF22152@irp-view7.cisco.com> To: v6ops@ops.ietf.org Subject: WG Last Call draft-ietf-v6ops*secur*overview* X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Folks This note starts the WG Last Call for comments on "IPv6 Transition/Co-existence Security Considerations", Elwyn Davies, 13-May-05, It may be found on http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-00.txt The document's proposed status is Informational. Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. This Last Call will end two weeks from today at Close of Business PDT. Thanks, Fred From owner-v6ops@ops.ietf.org Mon Jun 6 09:02:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28322 for ; Mon, 6 Jun 2005 09:02:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfHDc-000L6j-P0 for v6ops-data@psg.com; Mon, 06 Jun 2005 13:00:40 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfHDb-000L61-Ag for v6ops@ops.ietf.org; Mon, 06 Jun 2005 13:00:39 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Jun 2005 06:00:40 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j56D0Rlw018330 for ; Mon, 6 Jun 2005 06:00:28 -0700 (PDT) From: fred@cisco.com Received: (fred@localhost) by irp-view7.cisco.com (8.11.2/CISCO.WS.1.2) id j56D0Ui22032 for v6ops@ops.ietf.org; Mon, 6 Jun 2005 06:00:30 -0700 (PDT) Date: Mon, 6 Jun 2005 06:00:30 -0700 (PDT) Message-Id: <200506061300.j56D0Ui22032@irp-view7.cisco.com> To: v6ops@ops.ietf.org Subject: WG Last Call draft-ietf-v6ops-nap* X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Folks This note starts the WG Last Call for comments on "IPv6 Network Architecture Protection", Gunter Van de Velde, 28-Mar-05, It may be found on http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-00.txt The document's proposed status is Informational. Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. This Last Call will end two weeks from today at Close of Business PDT. Thanks, Fred From owner-v6ops@ops.ietf.org Mon Jun 6 12:13:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13601 for ; Mon, 6 Jun 2005 12:13:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfKCP-000Df5-2K for v6ops-data@psg.com; Mon, 06 Jun 2005 16:11:37 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfKCM-000Den-53 for v6ops@ops.ietf.org; Mon, 06 Jun 2005 16:11:35 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id F3C1A556E; Mon, 6 Jun 2005 18:11:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id F025E5516; Mon, 6 Jun 2005 18:11:31 +0200 (CEST) Date: Mon, 6 Jun 2005 18:11:31 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Elwyn Davies Cc: v6ops@ops.ietf.org Subject: Re: Please comment on new draft: draft-ietf-v6ops-security-overview-00.txt In-Reply-To: <20050519110311.N54691@mignon.ki.iif.hu> Message-ID: <20050606180723.E82688@mignon.ki.iif.hu> References: <200505131947.PAA21538@ietf.org> <42850F82.7010300@dial.pipex.com> <20050519110311.N54691@mignon.ki.iif.hu> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1659216028-1118074291=:82688" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1659216028-1118074291=:82688 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Dear All, Sorry. I sent out earlier version of my comment this morning. I had to send it via on an unreliable wireless connection and I selected wrong version of the file. I send in an attachment now. Sorry again. Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Mon, 6 Jun 2005, Mohacsi Janos wrote: > Hi Elwyn, > Here I have some comments to draft-ietf-v6ops-security-overview-00.txt > > For Section 4.2: > > An addional reason why IPv6 by Default may brings the usability down: > > - At enterprises, at service providers or even at universities, in most cases > the high availability is a big demand. The HA solutions nowadays are > implemented only for IPv6. There lack of real IPv6 support for HSRP, VRRP > (Virtual router reduncdancy protocol) [RFC3768] and even LVS (Linux Virtual > Server) [LVSURL], that makes IPv6 services less robust. > > For Section 4.5: > I would rewrite it in a following way: > > -----8<------------------------------------8<-------- > It is very common (although questionable) practice to filter completely the > ICMP messages in IPv4. This is no longer possible with IPv6. As the name > that it stands for suggests, Internet Control Message Protocol for IPv6 > [RFC2463] is the control and foundation protocol for the operation of IPv6, > not an auxiliary protocol that can be easily omitted. Our recommendation is > the following: > > o ICMPv6-echo-request and reply (Types 128 and 129): > > o You can consider enabling at least outgoing > ICMPv6-echo-request and their answers, the ICMPv6-echo-reply > packets to facilitate debugging. Of course, it is wise to rate > limit ICMPv6 debugging packets to a certain level. > > o You may consider enable incoming ICMPv6-echo-request packets > and their answers to your well know IPv6 service machines. You > should be sure, however, that your IPv6 service machine can handle > ICMPv6 requests at a certain rate. Of course, it is wise to rate > limit ICMPv6 debugging packets to a certain level. > > o ICMPv6-destination-unreachable (Type 1): > > o You should consider enabling incoming ICMPv6 destination > unreachable messages for debugging purpuse as an answers to > outgoing IPv6 packets that have been sent out. This should be > implemented with stateful packet inspection mechnanism as > described in 4.5.1. > > o You may generate and enable outgoing ICMPv6 destination > unreachable messages for all filtered packets. This is > useful for debugging. It is a common practice in IPv4, to refrain > from generating ICMPv6-destination-unreachable messages to hide > the networking/service structure. You can apply the same rule > to IPv6. If you generate ICMPv6-destination-unreachable > messages, however, do it properly, setting the right reason > code: no route to destination, administratively prohibited, beyond > scope of source address, address unreachable, port unreachable. > > o ICMPv6 packet too big (Type 2): > > o You must enable incoming ICMPv6-packet-too-big messages as > answers to outgoing IPv6 packets for the Path-MTU-discovery to > operate properly. > > o You must generate and allow outgoing ICMPv6-packet-too-big > messages properly if your MTU is different anywhere within your > network from the MTU on the link between you and your provider. > So be prepared, to forward ICMPv6-packet-too-big messages at the > firewall. > > o ICMPv6-time-exceeded (Type 3): > > o You must/should enable incoming ICMPv6-time-exceeded messages to > be able discover destination systems not reachable due to a low > TTL value in the outgoing packets. This should be implemented with > stateful packet inspection mechanisms to allow only answers to > sent out packet packets. > > o You can generate and allow outgoing ICMPv6-time-exceeded > messages since they are essential for proper operation > of Internet. > > > o ICMPv6-parameter-problem (Type 4): > > o You should consider enabling incoming ICMPv6-parameter-problem > messages as answers to outgoing IPv6 packets for debugging purpose. > > o You must generate correct and enable outgoing > ICMPv6-parameter-problem messages since they are essential for > proper operation of Internet. > > Needs futher investigation since it can be used to scan > services/networks if the attacker deliberatley sending packets with > wrong headers. > > > o ICMPv6-Neighbour-Solicitation and Neighbour-Advertisement (Type 135 and > 136): > > o You must enable incoming and outgoing ICMPv6 Neighbour-Solicitation, > Neighbour-Advertisement packets, with proper link-local addresses or > solicited node multicast addresses for the Neighbour Discovery > function to operate properly. > > o ICMPv6-Router-Solicitation and Router-Advertisement (Type 133 and 134): > > o If the Stateless Address Autoconfiguration function is used, you > must enable outgoing ICMPv6 Router-Advertisement packets, with > proper link-local addresses and multicast addresses (All node > multicast addresses ff02::1). > > o If the Stateless Address Autoconfiguration function is used, you > must enable incoming ICMPv6-Router-Solicitation packets, with proper > link-local addresses and multicast addresses (All router multicast > addresses ff02::2). > > o ICMPv6-redirect (Type 137): > > o You should disallow ICMPv6-router-redirect messages passing, if you > have only one exit router. However, router redundancy might be > implemented by router-redirect. It is important to know that > redirect has link-local meaning only. > > o ICMPv6 MLD listener query, listener report and listener done (Type 130, > 131 and 132): > > o You should enable incoming and outgoing ICMPv6 MLD messages, with > proper link-local addresses or multicast addresses if you want to use > IPv6 multicast on a bigger scope than link-local. This is required > if the "internet-router-firewall-protected network" architecture is > used. In this case your firewall should act as an MLD router. > > o ICMPv6-renumbering (Type 138): > > o You can disallow ICMPv6 router renumbering messages passing, since > router renumbering is not widely adopted. > > o ICMPv6 node information query and reply (Type 139 and 140): > > o You may disallow ICMPv6 node information query and reply processing, > since node information query/reply is not widely adopted. > > -----8<------------------------------------8<-------- > > One issue is not discussed sufficiently: > 2.1.13 Adress configuration Security (only suggested section number) > > Common method in IPv6 to supply an address for a (default) gateway and > other paramaters related to links is through Stateless Address > AutoConfiguration [RFC2462], DHCPv6 [RFC3646] or static configuration. > > 2.1.13.1 Fake router advertisments > > Routers consider authoritative the information carried in router > advertisements sent by other on-link routers, even though such > information is not cryptographically secured (e.g., digitally signed or > key-MACed or encrypted). Clients update the advertised > communication parameters accordingly, without any verification. In the > absence of any verification of the received information, malicious nodes > may inject bogus values for optional fields of the ICMPv6 extension > header, such as the advertised prefix, link layer address address of > next-hop router, HopLimit, various times for addresses or MTU. > > However there are some protection to prevent abuse: > - link MTU cannot be lower than 1280 according RFC2460 [RFC2460] > - the HopLimit cannot be lower than 32? > - Variauos constrains to address times > > A possible counter-measure that system/network administrators can query (all > routers link local address) ff02::2 constantly in order to identify any > "alien router" on the network segment or log router advertisement messages. > These type of solution is not an ideal one because it can only warn about an > anomaly, not really being able to prevent or correct it. > > Alternatively criptographical secured router advertisment should be > implemented. > > The use of DHCPv6 systems may also assist in preventing such rogue > configurations. > > 2.1.13.2 False DHCPv6 server > > TBD > > 2.1.13.3 Mismatching link-local and static parameters > > - maintainenance cost <- if renumbering or router change > > > --- > > > I hope this can improve the draft. > > Kindest Regards, > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > On Fri, 13 May 2005, Elwyn Davies wrote: > >> Hi. >> >> A new version of this draft (previously >> draft-savola-v6ops-security-overview) which is now a WG draft is available. >> >> Please let us have any comments asap - we intend to produce another new >> version incorporating any comments prior to IETF-63. >> >> This version incorporates a number of additional points contributed by >> SUZUKI Shinsuke for the Japan IPv6 Promotional Council as well as deal of >> updated wording. We are particularly interested on views of how we should >> proceed on the subject of ICMPv6 filtering in firewalls. >> >> Thanks, >> Elwyn Davies for the authors >> >> Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IPv6 Operations Working Group of the >>> IETF. >>> >>> Title : IPv6 Transition/Co-existence Security >>> Considerations >> > Author(s) : E. Davies, et al. >>> Filename : draft-ietf-v6ops-security-overview-00.txt >>> Pages : 32 >>> Date : 2005-5-13 >>> The transition from a pure IPv4 network to a network where IPv4 and >>> IPv6 co-exist brings a number of extra security considerations that >>> need to be taken into account when deploying IPv6 and operating the >>> dual-protocol network and the associated transition mechanisms. This >>> document attempts to give an overview of the various issues grouped >>> into three categories: >>> o issues due to the IPv6 protocol itself, >>> o issues due to transition mechanisms, and >>> o issues due to IPv6 deployment. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body of the >>> message. You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your >>> subscription settings. >>> >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username >>> "anonymous" and a password of your e-mail address. After logging in, >>> type "cd internet-drafts" and then >>> "get draft-ietf-v6ops-security-overview-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-v6ops-security-overview-00.txt". >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> Below is the data which will enable a MIME >>> compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> >> > > --0-1659216028-1118074291=:82688 Content-Type: TEXT/plain; charset=US-ASCII; name=v6op-security-comment.txt Content-ID: <20050606181131.I82688@mignon.ki.iif.hu> Content-Description: Content-Disposition: attachment; filename=v6op-security-comment.txt Content-Transfer-Encoding: BASE64 SGVyZSBJIGhhdmUgc29tZSBjb21tZW50cyAgdG8gIGRyYWZ0LWlldGYtdjZv cHMtc2VjdXJpdHktb3ZlcnZpZXctMDAudHh0DQoNCkZvciBTZWN0aW9uIDQu MjoNCg0KQW4gYWRkaXRpb25hbCByZWFzb24gd2h5IElQdjYgYnkgRGVmYXVs dCBtYXkgYnJpbmdzICB0aGUJdXNhYmlsaXR5ICBkb3duOg0KDQotIEF0IGVu dGVycHJpc2VzLCBhdCBzZXJ2aWNlIHByb3ZpZGVycyBvciBldmVuIGF0IHVu aXZlcnNpdGllcywgaW4gbW9zdCANCmNhc2VzIHRoZSBoaWdoIGF2YWlsYWJp bGl0eSBpcyBhIGJpZyBkZW1hbmQuICBUaGUgSEEgc29sdXRpb25zIG5vd2Fk YXlzIA0KYXJlIGltcGxlbWVudGVkIG9ubHkgZm9yIElQdjYuIFRoZXJlIGxh Y2sgb2YgcmVhbCBJUHY2IHN1cHBvcnQgZm9yIEhTUlAsIA0KVlJSUCAoVmly dHVhbCByb3V0ZXIgcmVkdW5kYW5jeSBwcm90b2NvbCkgIFtSRkMzNzY4XSBh bmQgZXZlbiBMVlMgKExpbnV4IA0KVmlydHVhbCBTZXJ2ZXIpICBbTFZTVVJM XSwgdGhhdCBtYWtlcyBJUHY2IHNlcnZpY2VzIGxlc3Mgcm9idXN0Lg0KDQpG b3IgU2VjdGlvbiA0LjU6DQpJIHdvdWxkIHJld3JpdGUgaXQgaW4gYSBmb2xs b3dpbmcgd2F5Og0KDQotLS0tLTg8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tODwtLS0tLS0tLQ0KSXQgaXMgdmVyeSBjb21tb24gKGFs dGhvdWdoIHF1ZXN0aW9uYWJsZSkgcHJhY3RpY2UgdG8gZmlsdGVyIGNvbXBs ZXRlbHkgDQp0aGUgSUNNUCBtZXNzYWdlcyBpbiBJUHY0LiAgVGhpcyBpcyBu byBsb25nZXIgcG9zc2libGUgd2l0aCBJUHY2LiAgQXMgdGhlIA0KbmFtZSB0 aGF0IGl0IHN0YW5kcyBmb3Igc3VnZ2VzdHMsIEludGVybmV0IENvbnRyb2wg TWVzc2FnZSBQcm90b2NvbCBmb3IgDQpJUHY2IFtSRkMyNDYzXSBpcyB0aGUg Y29udHJvbCBhbmQgZm91bmRhdGlvbiBwcm90b2NvbCBmb3IgdGhlIG9wZXJh dGlvbiBvZiANCklQdjYsIG5vdCBhbiBhdXhpbGlhcnkgcHJvdG9jb2wgdGhh dCBjYW4gYmUgZWFzaWx5IG9taXR0ZWQuICBPdXIgDQpyZWNvbW1lbmRhdGlv biBpcyB0aGUgZm9sbG93aW5nOg0KDQpvICBJQ01QdjYtZWNoby1yZXF1ZXN0 ICAgIGFuZAkgIHJlcGx5ICAgIChUeXBlcyAgICAxMjggICAgYW5kICAgIDEy OSk6DQoNCiAgIG8gIFlvdSAgY2FuICBjb25zaWRlciAgZW5hYmxpbmcgIGF0 ICBsZWFzdCAgb3V0Z29pbmcgIA0KICAgICAgSUNNUHY2LWVjaG8tcmVxdWVz dCBhbmQgdGhlaXIgYW5zd2VycywgdGhlIElDTVB2Ni1lY2hvLXJlcGx5DQog ICAgICBwYWNrZXRzIHRvIGZhY2lsaXRhdGUgZGVidWdnaW5nLiAgT2YgY291 cnNlLCBpdCBpcyB3aXNlIHRvIHJhdGUNCiAgICAgIGxpbWl0IElDTVB2NiBk ZWJ1Z2dpbmcgcGFja2V0cyB0byBhIGNlcnRhaW4gbGV2ZWwuDQoNCiAgIG8g IFlvdSBtYXkgIGNvbnNpZGVyICBlbmFibGUgIGluY29taW5nICBJQ01QdjYt ZWNoby1yZXF1ZXN0ICBwYWNrZXRzICANCiAgICAgIGFuZCB0aGVpciBhbnN3 ZXJzIHRvIHlvdXIgd2VsbCBrbm93IElQdjYgc2VydmljZSBtYWNoaW5lcy4g IFlvdQ0KICAgICAgc2hvdWxkIGJlIHN1cmUsIGhvd2V2ZXIsIHRoYXQgeW91 ciBJUHY2IHNlcnZpY2UgbWFjaGluZSBjYW4gaGFuZGxlDQogICAgICBJQ01Q djYgcmVxdWVzdHMgYXQgYSBjZXJ0YWluIHJhdGUuICBPZiBjb3Vyc2UsIGl0 IGlzIHdpc2UgdG8gcmF0ZQ0KICAgICAgbGltaXQgSUNNUHY2IGRlYnVnZ2lu ZyBwYWNrZXRzIHRvIGEgY2VydGFpbiBsZXZlbC4NCg0KbyAgSUNNUHY2LWRl c3RpbmF0aW9uLXVucmVhY2hhYmxlIChUeXBlIDEpOg0KDQogICBvICBZb3Ug c2hvdWxkIGNvbnNpZGVyIGVuYWJsaW5nIGluY29taW5nIElDTVB2NiBkZXN0 aW5hdGlvbiAgDQogICAgICB1bnJlYWNoYWJsZSBtZXNzYWdlcyBmb3IgZGVi dWdnaW5nIHB1cnBvc2UgYXMgYW4gYW5zd2VycyB0bw0KICAgICAgb3V0Z29p bmcgSVB2NiBwYWNrZXRzIHRoYXQgaGF2ZSBiZWVuIHNlbnQgb3V0LiAgVGhp cyBzaG91bGQgYmUNCiAgICAgIGltcGxlbWVudGVkIHdpdGggc3RhdGVmdWwg cGFja2V0IGluc3BlY3Rpb24gbWVjaGFuaXNtIGFzDQogICAgICBkZXNjcmli ZWQgaW4gNC41LjEuDQoNCiAgICBvICBZb3UgbWF5IGdlbmVyYXRlIGFuZCBl bmFibGUgb3V0Z29pbmcgSUNNUHY2IGRlc3RpbmF0aW9uDQogICAgICAgdW5y ZWFjaGFibGUgbWVzc2FnZXMgZm9yIGFsbCBmaWx0ZXJlZCBwYWNrZXRzLiBU aGlzIGlzDQogICAgICAgdXNlZnVsIGZvciBkZWJ1Z2dpbmcuICBJdCBpcyBh IGNvbW1vbiBwcmFjdGljZSBpbiBJUHY0LCB0byByZWZyYWluDQogICAgICAg ZnJvbSBnZW5lcmF0aW5nIElDTVB2Ni1kZXN0aW5hdGlvbi11bnJlYWNoYWJs ZSBtZXNzYWdlcyB0byBoaWRlDQogICAgICAgdGhlIG5ldHdvcmtpbmcvc2Vy dmljZSBzdHJ1Y3R1cmUuIFlvdSBjYW4gYXBwbHkgdGhlIHNhbWUgcnVsZQ0K ICAgICAgIHRvIElQdjYuIElmIHlvdSBnZW5lcmF0ZSBJQ01QdjYtZGVzdGlu YXRpb24tdW5yZWFjaGFibGUNCiAgICAgICBtZXNzYWdlcywgaG93ZXZlciwg ZG8gaXQgcHJvcGVybHksIHNldHRpbmcgdGhlIHJpZ2h0IHJlYXNvbg0KICAg ICAgIGNvZGU6ICBubyByb3V0ZSB0byBkZXN0aW5hdGlvbiwgYWRtaW5pc3Ry YXRpdmVseSBwcm9oaWJpdGVkLCBiZXlvbmQgDQogICAgICAgc2NvcGUgb2Yg c291cmNlIGFkZHJlc3MsIGFkZHJlc3MgdW5yZWFjaGFibGUsIHBvcnQgdW5y ZWFjaGFibGUuDQoNCm8gIElDTVB2NiBwYWNrZXQgdG9vIGJpZyAoVHlwZSAy KToNCg0KICAgbyAgWW91ICBtdXN0ICBlbmFibGUgIGluY29taW5nICBJQ01Q djYtcGFja2V0LXRvby1iaWcgIG1lc3NhZ2VzICBhcyAgDQogICAgICBhbnN3 ZXJzIHRvIG91dGdvaW5nIElQdjYgcGFja2V0cyBmb3IgdGhlIFBhdGgtTVRV LWRpc2NvdmVyeSB0bw0KICAgICAgb3BlcmF0ZSBwcm9wZXJseS4NCg0KICAg byAgWW91IG11c3QgZ2VuZXJhdGUgYW5kIGFsbG93IG91dGdvaW5nICBJQ01Q djYtcGFja2V0LXRvby1iaWcJDQogICAgICBtZXNzYWdlcyBwcm9wZXJseSBp ZiB5b3VyIE1UVSBpcyBkaWZmZXJlbnQgYW55d2hlcmUgd2l0aGluIHlvdXIN CiAgICAgIG5ldHdvcmsgZnJvbSB0aGUgTVRVIG9uIHRoZSBsaW5rIGJldHdl ZW4geW91IGFuZCB5b3VyIHByb3ZpZGVyLg0KICAgICAgU28gYmUgcHJlcGFy ZWQsIHRvIGZvcndhcmQgSUNNUHY2LXBhY2tldC10b28tYmlnIG1lc3NhZ2Vz IGF0IHRoZQ0KICAgICAgZmlyZXdhbGwuDQoNCm8gIElDTVB2Ni10aW1lLWV4 Y2VlZGVkIChUeXBlIDMpOg0KDQogICBvICBZb3UgbXVzdC9zaG91bGQgZW5h YmxlIGluY29taW5nIElDTVB2Ni10aW1lLWV4Y2VlZGVkIG1lc3NhZ2VzICB0 byAgDQogICAgICBiZSBhYmxlIGRpc2NvdmVyIGRlc3RpbmF0aW9uIHN5c3Rl bXMgbm90IHJlYWNoYWJsZSBkdWUgdG8gYSBsb3cNCiAgICAgIFRUTCB2YWx1 ZSBpbiB0aGUgb3V0Z29pbmcgcGFja2V0cy4gVGhpcyBzaG91bGQgYmUgaW1w bGVtZW50ZWQgd2l0aA0KICAgICAgc3RhdGVmdWwgcGFja2V0IGluc3BlY3Rp b24gbWVjaGFuaXNtcyB0byBhbGxvdyBvbmx5IGFuc3dlcnMgdG8NCiAgICAg IHNlbnQgb3V0IHBhY2tldCBwYWNrZXRzLg0KDQogICBvICBZb3UgY2FuIGdl bmVyYXRlIGFuZCBhbGxvdyBvdXRnb2luZyBJQ01QdjYtdGltZS1leGNlZWRl ZA0KICAgICAgbWVzc2FnZXMgc2luY2UgdGhleSBhcmUgZXNzZW50aWFsIGZv ciBwcm9wZXIgb3BlcmF0aW9uDQogICAgICBvZiBJbnRlcm5ldC4NCg0KDQpv ICBJQ01QdjYtcGFyYW1ldGVyLXByb2JsZW0gKFR5cGUgNCk6DQoNCiAgIG8g IFlvdSBzaG91bGQgY29uc2lkZXIgZW5hYmxpbmcgaW5jb21pbmcgSUNNUHY2 LXBhcmFtZXRlci1wcm9ibGVtDQogICAgICBtZXNzYWdlcyBhcyBhbnN3ZXJz IHRvIG91dGdvaW5nIElQdjYgcGFja2V0cyBmb3IgZGVidWdnaW5nIHB1cnBv c2UuDQoNCiAgIG8gIFlvdSBtdXN0IGdlbmVyYXRlIGNvcnJlY3QgYW5kIGVu YWJsZSBvdXRnb2luZyANCiAgICAgIElDTVB2Ni1wYXJhbWV0ZXItcHJvYmxl bSBtZXNzYWdlcyBzaW5jZSB0aGV5IGFyZSBlc3NlbnRpYWwgZm9yIA0KICAg ICAgcHJvcGVyIG9wZXJhdGlvbiBvZiBJbnRlcm5ldC4NCg0KICAgTmVlZHMg ZnVydGhlciBpbnZlc3RpZ2F0aW9uIHNpbmNlIGl0IGNhbiBiZSB1c2VkIHRv IHNjYW4gDQogICBzZXJ2aWNlcy9uZXR3b3JrcyBpZiB0aGUgYXR0YWNrZXIg ZGVsaWJlcmF0ZWx5IHNlbmRpbmcgcGFja2V0cyB3aXRoIA0KICAgd3Jvbmcg aGVhZGVycy4NCg0KDQpvICBJQ01QdjYtTmVpZ2hib3VyLVNvbGljaXRhdGlv biBhbmQgTmVpZ2hib3VyLUFkdmVydGlzZW1lbnQgKFR5cGUgMTM1IGFuZCAN CiAgIDEzNik6DQoNCiAgIG8gWW91IG11c3QgZW5hYmxlIGluY29taW5nIGFu ZCBvdXRnb2luZyBJQ01QdjYgTmVpZ2hib3VyLVNvbGljaXRhdGlvbiwgDQog ICAgIE5laWdoYm91ci1BZHZlcnRpc2VtZW50IHBhY2tldHMsIHdpdGggcHJv cGVyIGxpbmstbG9jYWwgYWRkcmVzc2VzIG9yIA0KICAgICBzb2xpY2l0ZWQg bm9kZSBtdWx0aWNhc3QgYWRkcmVzc2VzIGZvciB0aGUgTmVpZ2hib3VyIERp c2NvdmVyeSANCiAgICAgZnVuY3Rpb24gdG8gb3BlcmF0ZSBwcm9wZXJseS4N Cg0KbyAgSUNNUHY2LVJvdXRlci1Tb2xpY2l0YXRpb24gYW5kIFJvdXRlci1B ZHZlcnRpc2VtZW50IChUeXBlIDEzMyBhbmQgMTM0KToNCg0KICAgbyAgSWYg dGhlIFN0YXRlbGVzcyBBZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uIGZ1bmN0 aW9uIGlzIHVzZWQsIHlvdSANCiAgICAgIG11c3QgZW5hYmxlIG91dGdvaW5n IElDTVB2NiBSb3V0ZXItQWR2ZXJ0aXNlbWVudCBwYWNrZXRzLCB3aXRoIA0K ICAgICAgcHJvcGVyIGxpbmstbG9jYWwgYWRkcmVzc2VzIGFuZCBtdWx0aWNh c3QgYWRkcmVzc2VzIChBbGwgbm9kZSANCiAgICAgIG11bHRpY2FzdCBhZGRy ZXNzZXMgZmYwMjo6MSkuDQoNCiAgIG8gIElmIHRoZSBTdGF0ZWxlc3MgQWRk cmVzcyBBdXRvY29uZmlndXJhdGlvbiBmdW5jdGlvbiBpcyB1c2VkLCB5b3Ug DQogICAgICBtdXN0IGVuYWJsZSBpbmNvbWluZyBJQ01QdjYtUm91dGVyLVNv bGljaXRhdGlvbiBwYWNrZXRzLCB3aXRoIHByb3BlciANCiAgICAgIGxpbmst bG9jYWwgYWRkcmVzc2VzIGFuZCBtdWx0aWNhc3QgYWRkcmVzc2VzIChBbGwg cm91dGVyIG11bHRpY2FzdCANCiAgICAgIGFkZHJlc3NlcyBmZjAyOjoyKS4N Cg0KbyAgSUNNUHY2LXJlZGlyZWN0IChUeXBlIDEzNyk6DQoNCiAgIG8gIFlv dSBzaG91bGQgZGlzYWxsb3cgSUNNUHY2LXJvdXRlci1yZWRpcmVjdCBtZXNz YWdlcyBwYXNzaW5nLCBpZiB5b3UgDQogICAgICBoYXZlIG9ubHkgb25lIGV4 aXQgcm91dGVyLiBIb3dldmVyLCByb3V0ZXIgcmVkdW5kYW5jeSBtaWdodCBi ZSANCiAgICAgIGltcGxlbWVudGVkIGJ5IHJvdXRlci1yZWRpcmVjdC4gIEl0 IGlzIGltcG9ydGFudCB0byBrbm93IHRoYXQgDQogICAgICByZWRpcmVjdCBo YXMgbGluay1sb2NhbCBtZWFuaW5nIG9ubHkuDQoNCm8gIElDTVB2NiBNTEQg bGlzdGVuZXIgcXVlcnksIGxpc3RlbmVyIHJlcG9ydCBhbmQgbGlzdGVuZXIg ZG9uZSAoVHlwZSAxMzAsIA0KMTMxIGFuZCAxMzIpOg0KDQogIG8gIFlvdSBz aG91bGQgZW5hYmxlIGluY29taW5nIGFuZCBvdXRnb2luZyBJQ01QdjYgTUxE IG1lc3NhZ2VzLCB3aXRoIA0KICAgICBwcm9wZXIgbGluay1sb2NhbCBhZGRy ZXNzZXMgb3IgbXVsdGljYXN0IGFkZHJlc3NlcyBpZiB5b3Ugd2FudCB0byB1 c2UgDQogICAgIElQdjYgbXVsdGljYXN0IG9uIGEgYmlnZ2VyIHNjb3BlIHRo YW4gbGluay1sb2NhbC4gVGhpcyBpcyByZXF1aXJlZA0KICAgICBpZiB0aGUg ImludGVybmV0LXJvdXRlci1maXJld2FsbC1wcm90ZWN0ZWQgbmV0d29yayIg IGFyY2hpdGVjdHVyZSBpcyANCiAgICAgdXNlZC4gSW4gdGhpcyBjYXNlIHlv dXIgZmlyZXdhbGwgc2hvdWxkIGFjdCBhcyBhbiBNTEQgcm91dGVyLg0KDQpv ICBJQ01QdjYtcmVudW1iZXJpbmcgKFR5cGUgMTM4KTogDQoNCiAgbyAgWW91 IGNhbiBkaXNhbGxvdyBJQ01QdjYgcm91dGVyIHJlbnVtYmVyaW5nIG1lc3Nh Z2VzIHBhc3NpbmcsIHNpbmNlIA0KICAgICByb3V0ZXIgcmVudW1iZXJpbmcg aXMgbm90IHdpZGVseSBhZG9wdGVkLg0KDQpvICBJQ01QdjYgbm9kZSBpbmZv cm1hdGlvbiBxdWVyeSBhbmQgcmVwbHkgKFR5cGUgMTM5IGFuZCAxNDApOg0K DQogIG8gIFlvdSBtYXkgZGlzYWxsb3cgSUNNUHY2IG5vZGUgaW5mb3JtYXRp b24gcXVlcnkgYW5kIHJlcGx5IHByb2Nlc3NpbmcsIA0KICAgICBzaW5jZSBu b2RlIGluZm9ybWF0aW9uIHF1ZXJ5L3JlcGx5IGlzIG5vdCB3aWRlbHkgYWRv cHRlZC4NCg0KLS0tLS04PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTg8LS0tLS0tLS0NCg0KT25lIGlzc3VlIGlzIG5vdCBkaXNjdXNz ZWQgc3VmZmljaWVudGx5Og0KMi4xLjEzIEFkZHJlc3MgY29uZmlndXJhdGlv biBTZWN1cml0eSAob25seSBzdWdnZXN0ZWQgc2VjdGlvbiBudW1iZXIpDQoN CkNvbW1vbiBtZXRob2QgaW4gSVB2NiB0byBzdXBwbHkgYW4gYWRkcmVzcyBm b3IgYSAoZGVmYXVsdCkgZ2F0ZXdheSBhbmQNCm90aGVyIHBhcmFtZXRlcnMg cmVsYXRlZCB0byBsaW5rcyBpcyB0aHJvdWdoIFN0YXRlbGVzcyBBZGRyZXNz DQpBdXRvQ29uZmlndXJhdGlvbiBbUkZDMjQ2Ml0sIERIQ1B2NiBbUkZDMzY0 Nl0gb3Igc3RhdGljIGNvbmZpZ3VyYXRpb24uIA0KDQoyLjEuMTMuMSBGYWtl IHJvdXRlciBhZHZlcnRpc2VtZW50cw0KDQpSb3V0ZXJzIGNvbnNpZGVyIGF1 dGhvcml0YXRpdmUgdGhlIGluZm9ybWF0aW9uIGNhcnJpZWQgaW4gcm91dGVy DQphZHZlcnRpc2VtZW50cyBzZW50IGJ5IG90aGVyIG9uLWxpbmsgcm91dGVy cywgZXZlbiB0aG91Z2ggc3VjaA0KaW5mb3JtYXRpb24gaXMgbm90IGNyeXB0 b2dyYXBoaWNhbGx5IHNlY3VyZWQgKGUuZy4sIGRpZ2l0YWxseSBzaWduZWQg b3INCmtleS1NQUNlZCBvciBlbmNyeXB0ZWQpLiBDbGllbnRzIHVwZGF0ZSB0 aGUgYWR2ZXJ0aXNlZA0KY29tbXVuaWNhdGlvbiBwYXJhbWV0ZXJzIGFjY29y ZGluZ2x5LCB3aXRob3V0IGFueSB2ZXJpZmljYXRpb24uIEluIHRoZQ0KYWJz ZW5jZSBvZiBhbnkgdmVyaWZpY2F0aW9uIG9mIHRoZSByZWNlaXZlZCBpbmZv cm1hdGlvbiwgbWFsaWNpb3VzIG5vZGVzDQptYXkgaW5qZWN0IGJvZ3VzIHZh bHVlcyBmb3Igb3B0aW9uYWwgZmllbGRzIG9mIHRoZSBJQ01QdjYgZXh0ZW5z aW9uDQpoZWFkZXIsIHN1Y2ggYXMgdGhlIGFkdmVydGlzZWQgcHJlZml4LCBs aW5rIGxheWVyIGFkZHJlc3MgYWRkcmVzcyBvZg0KbmV4dC1ob3Agcm91dGVy LCBIb3BMaW1pdCwgdmFyaW91cyB0aW1lcyBmb3IgYWRkcmVzc2VzIG9yIE1U VS4gDQoNCkhvd2V2ZXIgdGhlcmUgYXJlIHNvbWUgcHJvdGVjdGlvbiB0byBw cmV2ZW50IGFidXNlOg0KLSBsaW5rIE1UVSBjYW5ub3QgYmUgbG93ZXIgdGhh biAxMjgwIGFjY29yZGluZyBSRkMyNDYwIFtSRkMyNDYwXQ0KLSB0aGUgSG9w TGltaXQgY2Fubm90IGJlIGxvd2VyIHRoYW4gNjQgW0FTU0lHTkVEXT8NCi0g dmFyaW91cyBjb25zdHJhaW5zIHRvIGFkZHJlc3MgdGltZXMNCg0KQSBwb3Nz aWJsZSBjb3VudGVyLW1lYXN1cmUgdGhhdCBzeXN0ZW0vbmV0d29yayBhZG1p bmlzdHJhdG9ycyBjYW4gcXVlcnkgDQooYWxsIHJvdXRlcnMgbGluayBsb2Nh bCBhZGRyZXNzKSBmZjAyOjoyIGNvbnN0YW50bHkgaW4gb3JkZXIgdG8gaWRl bnRpZnkgDQphbnkgImFsaWVuIHJvdXRlciIgb24gdGhlIG5ldHdvcmsgc2Vn bWVudCBvciBsb2cgcm91dGVyIGFkdmVydGlzZW1lbnQgDQptZXNzYWdlcy4g VGhlc2UgdHlwZSBvZiBzb2x1dGlvbiBpcyBub3QgYW4gaWRlYWwgb25lIGJl Y2F1c2UgaXQgY2FuIG9ubHkgDQp3YXJuIGFib3V0IGFuIGFub21hbHksIG5v dCByZWFsbHkgYmVpbmcgYWJsZSB0byBwcmV2ZW50IG9yIGNvcnJlY3QgaXQu DQoNCkFsdGVybmF0aXZlbHkgY3J5cHRvZ3JhcGhpY2FsIHNlY3VyZWQgcm91 dGVyIGFkdmVydGlzZW1lbnQgc2hvdWxkIGJlDQppbXBsZW1lbnRlZC4NCg0K VGhlIHVzZSBvZiBESENQdjYgc3lzdGVtcyBtYXkgYWxzbyBhc3Npc3QgaW4g cHJldmVudGluZyBzdWNoIHJvZ3VlDQpjb25maWd1cmF0aW9ucy4NCg0KMi4x LjEzLjIgRmFsc2UgREhDUHY2IHNlcnZlcg0KDQpUQkQNCg0KMi4xLjEzLjMg TWlzbWF0Y2hpbmcgbGluay1sb2NhbCBhbmQgc3RhdGljIHBhcmFtZXRlcnMN Cg0KLSBtYWludGVuYW5jZSBjb3N0IDwtIGlmIHJlbnVtYmVyaW5nIG9yIHJv dXRlciBjaGFuZ2UNCg0K --0-1659216028-1118074291=:82688-- From owner-v6ops@ops.ietf.org Tue Jun 7 10:10:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25953 for ; Tue, 7 Jun 2005 10:10:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfejL-000CrY-W6 for v6ops-data@psg.com; Tue, 07 Jun 2005 14:06:59 +0000 Received: from [210.84.237.40] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfejJ-000CrA-ER for v6ops@ops.ietf.org; Tue, 07 Jun 2005 14:06:58 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id DFDAC62AAE for ; Tue, 7 Jun 2005 23:36:53 +0930 (CST) Date: Tue, 7 Jun 2005 23:36:53 +0930 From: Mark Smith To: v6ops@ops.ietf.org Subject: Re: WG Last Call draft-ietf-v6ops*secur*overview* Message-Id: <20050607233653.744e371a.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <200506061300.j56D0WF22152@irp-view7.cisco.com> References: <200506061300.j56D0WF22152@irp-view7.cisco.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On Mon, 6 Jun 2005 06:00:32 -0700 (PDT) fred@cisco.com wrote: > Folks > > This note starts the WG Last Call for comments on > > "IPv6 Transition/Co-existence Security Considerations", Elwyn Davies, > 13-May-05, > "Appendix A. IPv6 Probing/Mapping Considerations" . . . "For example, automatic tunneling mechanisms use rather deterministic methods for generating IPv6 addresses, so probing/port-scanning an IPv6 node is simplified. The IPv4 address is embedded at least in 6to4, Teredo and ISATAP address. Further than that, it's possible (in the case of 6to4 in particular) to learn the address behind the prefix; for example, Microsoft 6to4 implementation uses the address 2002:V4ADDR::V4ADDR while Linux and BSD implementations default to 2002:V4ADDR::1. This could also be used as one way to identify an implementation." "IPv4-compatible IPv6 addresses" could be worth describing as an even better example of IPv6 tunnel end point address that is directly deterministic from an IPv4 address. I'm finding that on my Linux 6to4 tunnel interface, they are automatically configured, which surprised me a bit. I'm also getting an automatic ::/96 route pointing out my 6to4 tunnel which I don't think makes sense. Looking at RFC2893, it seems that automatic assignment and a ::/96 route should happen if the OS supports "IPv4-compatible IPv6 addresses". Possibly (thinking about it a bit more, probably) this could be considered a Linux bug, as Linux isn't considering the difference between a "IPv4-compatible IPv6 address" tunnel and a 6to4 tunnel. Even if it is, I think automatic "IPv4-compatible IPv6 addresses" on appropriate tunnels on Linux and other OSes would be an IPv6 security concern, and therefore probably mentioned in this draft. A minor nit. I'm not sure about the Linux default interface address of ::1 for 6to4 tunnels. Using either of the ifconfig and iproute2 utilities, I don't seem to be able specify a prefix without a node address for a 6to4 tunnel, therefore asking Linux to select an interface address. I'd suggest the "default" interface address of Linux 6to4 tunnels is ::1 probably only because of human nature when configuring the local 6to4 tunnel end point IPv6 address. Regards, Mark. From owner-v6ops@ops.ietf.org Tue Jun 7 11:17:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02022 for ; Tue, 7 Jun 2005 11:17:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dffng-000JTw-Iu for v6ops-data@psg.com; Tue, 07 Jun 2005 15:15:32 +0000 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dffnc-000JSI-11 for v6ops@ops.ietf.org; Tue, 07 Jun 2005 15:15:28 +0000 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Dffna-0001rV-1Y; Tue, 07 Jun 2005 16:15:26 +0100 Message-ID: <42A5BA4C.5000300@dial.pipex.com> Date: Tue, 07 Jun 2005 16:16:28 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Smith CC: v6ops@ops.ietf.org Subject: Re: WG Last Call draft-ietf-v6ops*secur*overview* References: <200506061300.j56D0WF22152@irp-view7.cisco.com> <20050607233653.744e371a.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050607233653.744e371a.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the comments: Responses embedded below... Mark Smith wrote: >Hi, > >On Mon, 6 Jun 2005 06:00:32 -0700 (PDT) >fred@cisco.com wrote: > > > >>Folks >> >>This note starts the WG Last Call for comments on >> >> "IPv6 Transition/Co-existence Security Considerations", Elwyn Davies, >> 13-May-05, >> >> >> > >"Appendix A. IPv6 Probing/Mapping Considerations" > >. >. >. > >"For example, automatic tunneling mechanisms use rather deterministic > methods for generating IPv6 addresses, so probing/port-scanning an > IPv6 node is simplified. The IPv4 address is embedded at least in > 6to4, Teredo and ISATAP address. Further than that, it's possible > (in the case of 6to4 in particular) to learn the address behind the > prefix; for example, Microsoft 6to4 implementation uses the address > 2002:V4ADDR::V4ADDR while Linux and BSD implementations default to > 2002:V4ADDR::1. This could also be used as one way to identify an > implementation." > >"IPv4-compatible IPv6 addresses" could be worth describing as an even >better example of IPv6 tunnel end point address that is directly >deterministic from an IPv4 address. > > The latest addressing architecture deprecates these addresses and v6ops is not recommending any mechanisms that use this kind of address, so I think I would prefer not to talk about IPv4 compatibles, even if they were once an issue. >I'm finding that on my Linux 6to4 tunnel interface, they are >automatically configured, which surprised me a bit. I'm also getting an >automatic ::/96 route pointing out my 6to4 tunnel which I don't think >makes sense. Looking at RFC2893, it seems that automatic assignment and a >::/96 route should happen if the OS supports "IPv4-compatible IPv6 >addresses". > >Possibly (thinking about it a bit more, probably) this could be >considered a Linux bug, as Linux isn't considering the difference >between a "IPv4-compatible IPv6 address" tunnel and a 6to4 tunnel. Even >if it is, I think automatic "IPv4-compatible IPv6 addresses" on >appropriate tunnels on Linux and other OSes would be an IPv6 security >concern, and therefore probably mentioned in this draft. > >A minor nit. I'm not sure about the Linux default interface address of >::1 for 6to4 tunnels. Using either of the ifconfig and iproute2 utilities, I >don't seem to be able specify a prefix without a node address for a 6to4 >tunnel, therefore asking Linux to select an interface address. I'd >suggest the "default" interface address of Linux 6to4 tunnels is ::1 >probably only because of human nature when configuring the local 6to4 >tunnel end point IPv6 address. > > Do you want to alter the text? It currently states that Linux and BSD *default* to xx::1, which means that a more fastidious human has the option to do something else. Does it really need any more text? Regards, Elwyn >Regards, >Mark. > > > From owner-v6ops@ops.ietf.org Tue Jun 7 11:55:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05131 for ; Tue, 7 Jun 2005 11:55:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfgPZ-000Mw2-Qc for v6ops-data@psg.com; Tue, 07 Jun 2005 15:54:41 +0000 Received: from [210.84.228.235] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfgPW-000MvX-Kx for v6ops@ops.ietf.org; Tue, 07 Jun 2005 15:54:39 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 63DE462AAE; Wed, 8 Jun 2005 01:24:35 +0930 (CST) Date: Wed, 8 Jun 2005 01:24:35 +0930 From: Mark Smith To: Elwyn Davies Cc: v6ops@ops.ietf.org Subject: Re: WG Last Call draft-ietf-v6ops*secur*overview* Message-Id: <20050608012435.139d935d.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <42A5BA4C.5000300@dial.pipex.com> References: <200506061300.j56D0WF22152@irp-view7.cisco.com> <20050607233653.744e371a.ipng@69706e6720323030352d30312d31340a.nosense.org> <42A5BA4C.5000300@dial.pipex.com> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Elwyn, On Tue, 07 Jun 2005 16:16:28 +0100 Elwyn Davies wrote: > Thanks for the comments: > No worries. Hope they're useful. > > > >"Appendix A. IPv6 Probing/Mapping Considerations" > > > >. > >. > >. > > > >"For example, automatic tunneling mechanisms use rather deterministic > > methods for generating IPv6 addresses, so probing/port-scanning an > > IPv6 node is simplified. The IPv4 address is embedded at least in > > 6to4, Teredo and ISATAP address. Further than that, it's possible > > (in the case of 6to4 in particular) to learn the address behind the > > prefix; for example, Microsoft 6to4 implementation uses the address > > 2002:V4ADDR::V4ADDR while Linux and BSD implementations default to > > 2002:V4ADDR::1. This could also be used as one way to identify an > > implementation." > > > >"IPv4-compatible IPv6 addresses" could be worth describing as an even > >better example of IPv6 tunnel end point address that is directly > >deterministic from an IPv4 address. > > > > > The latest addressing architecture deprecates these addresses and v6ops > is not recommending any mechanisms that use this kind of address, so I > think I would prefer not to talk about IPv4 compatibles, even if they > were once an issue. > Oh, ok. I've seen it being discussed on the MLs, although I wasn't reading the threads. I though it was only discussing the "IPv4-mapped IPv6 Addresses" this draft discusses in section 2.2, specifically representing an IPv4 address as an IPv6 address within the OS. I'm not really a programmer, and I thought that the discussion was only covering the IPv6 APIs and related IPv4/IPv6 issues. Just to make sure we're both talking about the same things, are "IPv4-mapped IPv6 Addresses" the same as "IPv4-compatible IPv6 addresses" ? The text in this draft says : "the use of IPv4-mapped addresses has been extended to a transition mechanism, Stateless IP/ICMP Translation algorithm (SIIT) [RFC2765], where they are potentially used in the addresses of packets on the wire." which I read to mean that before SIIT (RFC date February 2000), "IPv4-mapped addresses" wouldn't be seen on the wire. Yet the first "IPv4-compatible IPv6 addresses" RFC, RFC1933, is dated April 1996, indicating that IPv4-compatible IPv6 addresses would be seen on the wire prior to SIIT. That makes me wonder if we are talking about the same thing ? I'm happy to check the latest addressing architecture RFC or draft to find out myself if they are the same. If they are the same, this draft might benefit from using both terms in the above text at least once to show that they are the same thing. > >I'm finding that on my Linux 6to4 tunnel interface, they are > >automatically configured, which surprised me a bit. I'm also getting an > >automatic ::/96 route pointing out my 6to4 tunnel which I don't think > >makes sense. Looking at RFC2893, it seems that automatic assignment and a > >::/96 route should happen if the OS supports "IPv4-compatible IPv6 > >addresses". > > > >Possibly (thinking about it a bit more, probably) this could be > >considered a Linux bug, as Linux isn't considering the difference > >between a "IPv4-compatible IPv6 address" tunnel and a 6to4 tunnel. Even > >if it is, I think automatic "IPv4-compatible IPv6 addresses" on > >appropriate tunnels on Linux and other OSes would be an IPv6 security > >concern, and therefore probably mentioned in this draft. > > > >A minor nit. I'm not sure about the Linux default interface address of > >::1 for 6to4 tunnels. Using either of the ifconfig and iproute2 utilities, I > >don't seem to be able specify a prefix without a node address for a 6to4 > >tunnel, therefore asking Linux to select an interface address. I'd > >suggest the "default" interface address of Linux 6to4 tunnels is ::1 > >probably only because of human nature when configuring the local 6to4 > >tunnel end point IPv6 address. > > > > > Do you want to alter the text? It currently states that Linux and BSD > *default* to xx::1, which means that a more fastidious human has the > option to do something else. Does it really need any more text? > That's the thing. I can't get "Linux" itself to default to ::1, because I'm forced to specify a full IPv6 address, and being a lazy human _I'll_ pick ::1 by default for the interface ID. It seems that Linux itself doesn't have a default value at all, and it is not possible to make Linux pick one. If you've seen that "default" I think it is probably in the scripts to setup a 6to4 tunnel, and they are distribution dependent. I realise the difference is somewhat pedantic, however, I'd take a statement that "Linux defaults to ::1" to mean that all distributions based on the Linux kernel would default to ::1, and that may not be the case, or if it is today, may not be in the future. Thanks, Mark. From owner-v6ops@ops.ietf.org Tue Jun 7 12:16:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06877 for ; Tue, 7 Jun 2005 12:16:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dfgjn-000OtC-1W for v6ops-data@psg.com; Tue, 07 Jun 2005 16:15:35 +0000 Received: from [210.84.228.235] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dfgjl-000Osl-5S for v6ops@ops.ietf.org; Tue, 07 Jun 2005 16:15:33 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id E750E62B09; Wed, 8 Jun 2005 01:45:28 +0930 (CST) Date: Wed, 8 Jun 2005 01:45:28 +0930 From: Mark Smith To: elwynd@dial.pipex.com Cc: v6ops@ops.ietf.org Subject: Fw: Re: WG Last Call draft-ietf-v6ops*secur*overview* Message-Id: <20050608014528.218ede03.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Elwyn, > > > Do you want to alter the text? It currently states that Linux and BSD > *default* to xx::1, which means that a more fastidious human has the > option to do something else. Does it really need any more text? > To answer this question directly, maybe just delete "Linux", as the Linux kernel's local 6to4 tunnel end point address is defined by what ever the user space network configuration utilities set it to. Regards, Mark. From owner-v6ops@ops.ietf.org Tue Jun 7 13:24:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12967 for ; Tue, 7 Jun 2005 13:24:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfhnE-0004VQ-E5 for v6ops-data@psg.com; Tue, 07 Jun 2005 17:23:12 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DfhnC-0004VA-1s for v6ops@ops.ietf.org; Tue, 07 Jun 2005 17:23:10 +0000 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1DfhnA-0001Pb-8I; Tue, 07 Jun 2005 18:23:08 +0100 Message-ID: <42A5D83A.70504@dial.pipex.com> Date: Tue, 07 Jun 2005 18:24:10 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Smith CC: v6ops@ops.ietf.org Subject: Re: WG Last Call draft-ietf-v6ops*secur*overview* References: <200506061300.j56D0WF22152@irp-view7.cisco.com> <20050607233653.744e371a.ipng@69706e6720323030352d30312d31340a.nosense.org> <42A5BA4C.5000300@dial.pipex.com> <20050608012435.139d935d.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050608012435.139d935d.ipng@69706e6720323030352d30312d31340a.nosense.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Comments below Mark Smith wrote: >Hi Elwyn, > >On Tue, 07 Jun 2005 16:16:28 +0100 >Elwyn Davies wrote: > > > >>Thanks for the comments: >> >> >> > >No worries. Hope they're useful. > > > > > >>>"Appendix A. IPv6 Probing/Mapping Considerations" >>> >>>. >>>. >>>. >>> >>>"For example, automatic tunneling mechanisms use rather deterministic >>> methods for generating IPv6 addresses, so probing/port-scanning an >>> IPv6 node is simplified. The IPv4 address is embedded at least in >>> 6to4, Teredo and ISATAP address. Further than that, it's possible >>> (in the case of 6to4 in particular) to learn the address behind the >>> prefix; for example, Microsoft 6to4 implementation uses the address >>> 2002:V4ADDR::V4ADDR while Linux and BSD implementations default to >>> 2002:V4ADDR::1. This could also be used as one way to identify an >>> implementation." >>> >>>"IPv4-compatible IPv6 addresses" could be worth describing as an even >>>better example of IPv6 tunnel end point address that is directly >>>deterministic from an IPv4 address. >>> >>> >>> >>> >>The latest addressing architecture deprecates these addresses and v6ops >>is not recommending any mechanisms that use this kind of address, so I >>think I would prefer not to talk about IPv4 compatibles, even if they >>were once an issue. >> >> >> > >Oh, ok. I've seen it being discussed on the MLs, although I wasn't >reading the threads. I though it was only discussing the "IPv4-mapped >IPv6 Addresses" this draft discusses in section 2.2, specifically >representing an IPv4 address as an IPv6 address within the OS. I'm not >really a programmer, and I thought that the discussion was only covering >the IPv6 APIs and related IPv4/IPv6 issues. > >Just to make sure we're both talking about the same things, are >"IPv4-mapped IPv6 Addresses" the same as "IPv4-compatible IPv6 >addresses" ? > No! See S2.5.5 of http://www.ietf.org/internet-drafts/draft-ietf-ipv6-addr-arch-v4-04.txt >The text in this draft says : > >"the use of IPv4-mapped addresses > has been extended to a transition mechanism, Stateless IP/ICMP > Translation algorithm (SIIT) [RFC2765], where they are potentially > used in the addresses of packets on the wire." > >which I read to mean that before SIIT (RFC date February 2000), >"IPv4-mapped addresses" wouldn't be seen on the wire. Yet the first >"IPv4-compatible IPv6 addresses" RFC, RFC1933, is dated April 1996, >indicating that IPv4-compatible IPv6 addresses would be seen on the wire >prior to SIIT. That makes me wonder if we are talking about the same >thing ? > > Actually SIIT in its pure form is not something that anybody implements. The packet body translations are used in NAT-PT, but that is also headed off to experimental status, and anyway it does not use addresses with embedded IPv4 addresses in the same way. In general the opinion is that doing anything that shows either compatible or mapped addresses on the wire is a mistake: they are not routable and have the other problems you have mentioned. (this is already discussed in s2.2 of the security draft). >I'm happy to check the latest addressing architecture RFC or draft to >find out myself if they are the same. > >If they are the same, this draft might benefit from using both terms in >the above text at least once to show that they are the same thing. > > As noted above they aren't! > > >>>I'm finding that on my Linux 6to4 tunnel interface, they are >>>automatically configured, which surprised me a bit. I'm also getting an >>>automatic ::/96 route pointing out my 6to4 tunnel which I don't think >>>makes sense. Looking at RFC2893, it seems that automatic assignment and a >>>::/96 route should happen if the OS supports "IPv4-compatible IPv6 >>>addresses". >>> >>>Possibly (thinking about it a bit more, probably) this could be >>>considered a Linux bug, as Linux isn't considering the difference >>>between a "IPv4-compatible IPv6 address" tunnel and a 6to4 tunnel. Even >>>if it is, I think automatic "IPv4-compatible IPv6 addresses" on >>>appropriate tunnels on Linux and other OSes would be an IPv6 security >>>concern, and therefore probably mentioned in this draft. >>> >>>A minor nit. I'm not sure about the Linux default interface address of >>>::1 for 6to4 tunnels. Using either of the ifconfig and iproute2 utilities, I >>>don't seem to be able specify a prefix without a node address for a 6to4 >>>tunnel, therefore asking Linux to select an interface address. I'd >>>suggest the "default" interface address of Linux 6to4 tunnels is ::1 >>>probably only because of human nature when configuring the local 6to4 >>>tunnel end point IPv6 address. >>> >>> >>> >>> >>Do you want to alter the text? It currently states that Linux and BSD >>*default* to xx::1, which means that a more fastidious human has the >>option to do something else. Does it really need any more text? >> >> >> > >That's the thing. I can't get "Linux" itself to default to ::1, because >I'm forced to specify a full IPv6 address, and being a lazy human _I'll_ >pick ::1 by default for the interface ID. It seems that Linux itself >doesn't have a default value at all, and it is not possible to make >Linux pick one. If you've seen that "default" I think it is probably in >the scripts to setup a 6to4 tunnel, and they are distribution dependent. >I realise the difference is somewhat pedantic, however, I'd take a >statement that "Linux defaults to ::1" to mean that all distributions >based on the Linux kernel would default to ::1, and that may not be the >case, or if it is today, may not be in the future. > > > Would anybody else with deep knowledge of the Linux IPv6 implementation care to comment. Mark's other posting indicates that it the default in Linux has been removed and the text should be altered to reflect the current situation. Could a BSD expert also confirm whether the comment is still true for BSD please? Regards, Elwyn >Thanks, >Mark. > > > From owner-v6ops@ops.ietf.org Tue Jun 7 14:47:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21057 for ; Tue, 7 Jun 2005 14:47:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dfj4U-000B2C-HV for v6ops-data@psg.com; Tue, 07 Jun 2005 18:45:06 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dfj4N-000B0G-QJ for v6ops@ops.ietf.org; Tue, 07 Jun 2005 18:45:03 +0000 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:9b6:b32:4c3e:fec9]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4892B15218; Wed, 8 Jun 2005 03:48:14 +0900 (JST) Date: Wed, 08 Jun 2005 03:45:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Elwyn Davies Cc: Mark Smith , v6ops@ops.ietf.org Subject: Re: WG Last Call draft-ietf-v6ops*secur*overview* In-Reply-To: <42A5D83A.70504@dial.pipex.com> References: <200506061300.j56D0WF22152@irp-view7.cisco.com> <20050607233653.744e371a.ipng@69706e6720323030352d30312d31340a.nosense.org> <42A5BA4C.5000300@dial.pipex.com> <20050608012435.139d935d.ipng@69706e6720323030352d30312d31340a.nosense.org> <42A5D83A.70504@dial.pipex.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Tue, 07 Jun 2005 18:24:10 +0100, >>>>> Elwyn Davies said: >> That's the thing. I can't get "Linux" itself to default to ::1, because >> I'm forced to specify a full IPv6 address, and being a lazy human _I'll_ >> pick ::1 by default for the interface ID. It seems that Linux itself >> doesn't have a default value at all, and it is not possible to make >> Linux pick one. If you've seen that "default" I think it is probably in >> the scripts to setup a 6to4 tunnel, and they are distribution dependent. >> I realise the difference is somewhat pedantic, however, I'd take a >> statement that "Linux defaults to ::1" to mean that all distributions >> based on the Linux kernel would default to ::1, and that may not be the >> case, or if it is today, may not be in the future. >> > Would anybody else with deep knowledge of the Linux IPv6 implementation > care to comment. Mark's other posting indicates that it the default in > Linux has been removed and the text should be altered to reflect the > current situation. Could a BSD expert also confirm whether the comment > is still true for BSD please? FreeBSD (at least in 5.4 Release) seems to have the default IF ID of "...::1". It is set via a bootstrap script, so one may think "the default" is not an appropriate description (I personally don't have a particular opinion). BTW: BSD has many variants, and just saying "BSD" may be confusing. And, in fact, from a quick glance NetBSD or OpenBSD does not seem to have even a configuration knob for setting a 6to4 interface, and therefore they don't have the "default" IFID in any sense. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From 464jef@a-vip.com Thu Jun 9 13:08:24 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23151 for ; Thu, 9 Jun 2005 13:08:23 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQrX-0000EH-9K for v6ops-archive@ietf.org; Thu, 09 Jun 2005 13:30:40 -0400 Received: from dsl-80-42-94-85.access.as9105.com ([80.42.94.85]) by mx2.foretec.com with smtp (Exim 4.24) id 1DgQVu-000440-3P for v6ops-archive@ietf.org; Thu, 09 Jun 2005 13:08:19 -0400 Message-ID: From: "Vanessa J. Smith" <464jef@a-vip.com> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgQ3JlYXRpdmUgU3VpdGUgKDUgQ0QpIC0gd2hvbGVzYWxlIHByaWNl?= Date: Sat, 04 Jun 2005 03:48:40 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_BF661A96.BFBEBBAF" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.4 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_BF661A96.BFBEBBAF Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_BA932A0E.D7B189AF" ------=_NextPart_001_0001_BA932A0E.D7B189AF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the software you ever imagined for bottom prices! Our software is 2-10 times cheaper than sold by our competitors. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... For full list of products go: http://www.softavailable.com Regards, Vanessa Smith _____________________________________________________ To change your mail details, go: http://www.softavailable.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_BA932A0E.D7B189AF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get all the software you ever imagined for bottom prices!
Our software is 2-10 times cheaper than sold by our competitors.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... For full list of products go:

http://www.softavailable.com

Regards,
Vanessa Smith


_____________________________________________________
To change your mail details, go: http://www.softavailable.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_BA932A0E.D7B189AF-- ------=_NextPart_000_0000_BF661A96.BFBEBBAF-- From owner-v6ops@ops.ietf.org Fri Jun 10 16:46:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11238 for ; Fri, 10 Jun 2005 16:46:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgqLE-00079b-MC for v6ops-data@psg.com; Fri, 10 Jun 2005 20:43:00 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgqLB-00079K-29 for v6ops@ops.ietf.org; Fri, 10 Jun 2005 20:42:57 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 10 Jun 2005 13:42:57 -0700 X-IronPort-AV: i="3.93,190,1115017200"; d="txt'?scan'208"; a="642789902:sNHT53867500" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5AKgilw010647 for ; Fri, 10 Jun 2005 13:42:45 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5AKUmmV020090 for ; Fri, 10 Jun 2005 13:30:48 -0700 Mime-Version: 1.0 (Apple Message framework v622) To: "'v6ops@ops.ietf.org '" Message-Id: <9f02047a809826006692aebc8145e48f@cisco.com> Content-Type: multipart/mixed; boundary=Apple-Mail-5-542529573 From: Fred Baker Subject: Fwd: Appeal of decision to standardize "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail" Date: Fri, 10 Jun 2005 13:42:46 -0700 X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118435449.997690"; x:"432200"; a:"rsa-sha1"; b:"nofws:32213"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"d77eml5RleTfaylF+LFT7s1IvJnAgOeHHrQsyKfRWaPCHlWUuBcpt+ryUln21uG5d1HTFD70" "r4KWDcmmElHOYTcVrZcSgLl4SV+DI4xMWT78YyQEbPDGI58rfz94+A6AQkAJ8FHbQKt7vajAD+6" "eJ9G3UWmsJ4SYA0Z0WH4L/qU="; c:"From: Fred Baker "; c:"Subject: Fwd: Appeal of decision to standardize =22Mapping Between t" "he Multimedia Messaging Service (MMS) and Internet Mail=22"; c:"Date: Fri, 10 Jun 2005 13:42:46 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-5-542529573 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI - This is why it is necessary for us all to read and comment on documents. Without making a judgment on whether a screw-up occurred in the case John is concerned about, it is possible to have things get very screwed up if the WG participants each assume that someone else will do the indicated work. We have three last calls before V6OPS right now. Please read and comment on the drafts, if only to say "I'm in favor". Begin forwarded message: > From: John C Klensin > Date: June 10, 2005 11:49:17 AM PDT > To: Brian E Carpenter > Cc: Randall Gellens , iesg@ietf.org, ietf@ietf.org > Subject: Appeal of decision to standardize "Mapping Between the > Multimedia Messaging Service (MMS) and Internet Mail" > > Brian, > > This is a formal appeal addressed to you as IETF Chair and, if > necessary and appropriate, to the IESG, over the recent approval > of draft-ietf-lemonade-mms-mapping-04.txt, "Mapping Between the > Multimedia Messaging Service (MMS) and Internet Mail" as a > proposed standard. The appeal is self-contained and > self-explanatory and proposes both specific and general remedies > to the problems it identifies. It raises questions, not only of > technical content, but of the procedures used to review > documents within WGs as well as between WGs and other areas of > expertise and the mechanisms used to determine adequacy of IETF > consensus. > > The appeal necessarily takes no position on whether the problems > demonstrated by this particular document and its approval are > limited to it as an exceptional and deviant case or whether they > have more general implications, but perhaps that is a topic to > which the community should give some consideration in parallel > with your, and the IESG's, evaluation of the specific issues > raised. > > regards, > john --Apple-Mail-5-542529573 Content-Type: text/plain; x-unix-mode=0666; name="mms-mapping-appeal.txt" Content-Disposition: attachment; filename=mms-mapping-appeal.txt Content-Transfer-Encoding: 7bit This is an appeal of the approval by the IESG of "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail (draft-ietf-lemonade-mms-mapping-04.txt) as a Proposed Standard. The appeal specifies that the document, as written, (i) violates an important and long-standing design principle for Internet applications protocols, does so without compelling justification, and puts existing deployed and conforming programs at risk by doing so (ii) represents a process violation in that substantive changes were made to earlier versions without review and approval by the relevant WG (iii) contains a number of other errors or probably- inappropriate specifications that strengthen the impression that the document was approved by the IESG without adequate evidence of review and consensus in the WG and cross-area review in the community It requests that the IESG suspend or withdraw the Protocol Action Notice, that it refer the document back to the relevant WG, that the conflict with existing norms either be eliminated or strong justification for retaining it be provided to the IETF community and consensus demonstrated that an exception be justified, and that the WG be asked to review the other changes suggested. ------------------------ Details: When the LEMONADE WG was formed, it was established on the basis of an agreement that it would make no substantive changes to the Internet mail fabric. That agreement was spelled out in the charter, which said: A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. That agreement may have led to less intensive review of LEMONADE products, at least including this one, by members of the community who were not particularly concerned by work the WG did within the boundaries of that agreement and the scope statements based on it. To the degree to which the WG reached conclusions that pushed the boundaries of that agreement, an unusually high burden should be placed on it, and the responsible AD(s), to ensure that any specifications that could impact the existing email fabric are carefully reviewed in the broader community. Consensus must be demonstrated that the changes are both necessary and that they will not cause harm. Discussion with working group participants and review of the WG's mailing list archives indicates that the number of comments on this document received during WG Last Call was zero. Rather than meeting that high burden of review, there is no evidence at all that this document was examined by any significant fraction of the participants in the WG. This specification violates that principle and agreement. The handling of the specification as it passed through the WG and the IESG did not demonstrate the exceptional standard of care and review that is required to avoid interfering with the Internet's email fabric. It was also procedurally irregular even within normal standards of WG and community review. In particular, substantive changes were made to the specification between the version that was Last Called (-02) and the version approved by the IESG (-04), but a review of the WG's mailing list archive does not show any indication of WG review or discussion of those changes or of the newer drafts. Indeed, a review of the WG's archives did not show evidence of any review or discussion of this document in the last year and a half. We believe that any post-Last-Call revisions to the substance of a WG-produced specification must be sent back to that working group for review and approval, especially if it is probable that the need for the changes resulted from lack of adequate WG consideration in the first place. The overall conclusion that led to this appeal was that the document is severely defective in several ways and that there is no evidence that it represents proper review or consensus in the WG or the IETF more generally. Some, but not all, of what the appeal considers to be defects might be acceptable in a Proposed Standard if they had been carefully considered as tradeoffs within relevant communities of experts, but there is no evidence --in the document or in the WG archives-- that has been done. Other defects violate important principles of Internet mail and should not be permitted except in the absence of plausible alternatives and evidence of overwhelming support. Some fractions of these issues, but by no means all of them are, at least individually and in the opinion of those lodging the appeal, consistent with the types of rough edges that can be tolerated, indeed expected, in a Proposed Standard and could be noted simply for future reference and attention if and when the specification is proposed for advancement to the next maturity level. They are included here, as noted above, largely to illustrate that review and consensus about this document has been inadequate. There appears to be significant risk of harm if this document goes forward as standards-track implementation guidance for the public Internet. On the assumption that they will be corrected by the RFC Editor's process, this appeal does not address instances of bad grammar that make the document harder to follow that is desirable. Each identified problem below is followed by a brief statement of "REMEDY", which is a recommendation about what should be done if that portion of the appeal is judged to be valid. Specifically: (1) In order to allow extensions by private agreements among interchanging parties, the original definitions of the file transfer protocol provided that commands starting in "X" would always be treated as for private use and that such commands would never be standardized. That model was carried forward into the email system as private-extension commands in SMTP and private-extension ("X-") headers in RFC 822. In each case, the principle has been that we do not standardize such headers or assign semantics to them in standards-track specifications. Not only do Email systems all over the net assume that such headers can be safely discarded, but we have, for years, told the designers of such systems that they cannot rely on the interpretation of any such header in the absence of specific bilateral agreements (and presumed authentication to at least some level) with the initiator. The requirement that X-headers be treated in a special way was relaxed with the adoption of RFC 2822, but remains controversial. At best, it is unwise to violate the principle in this document unless doing so is necessary or represents extremely well-established operational practice. This specification violates those principles. It provides, e.g., that an X-MMS-Message-ID arriving from the MMS side "SHOULD" be mapped into an identically-named header on the Internet side to facilitate interpretation and conversion of that header back into an MMS environment. The problem here is not that the MMS environment has an X-MMS-Message-ID header (their problem, not IETF's) or that a mapping is required (although that issue is discussed below), but that the recommended _Internet_ is "X-MMS-Message-ID" and not "Message-ID" or "MMS-Message-ID". While the risk of problems is probably low, the principle is important. More important, there is no justification for violating the principle: the guidance given in RFC 2822 (and 822 before it) makes it clear that the WG could simply define and register "MMS-Message-ID:", translate whatever relevant form appears in the MMS environment into it, and then translate back as needed, without violating the "X-" rule or incurring even a slight risk of conflicts or ambiguity. Similar comments apply to X-Priority. The specification indicates how the X-MMS-Priority header on the MMS side can be mapped to the widely-used "Importance:" header on the Internet side. But it then specifies that it is reasonable to map X-MMS-Priority to "X-Priority:" and then assigns specific field values to the latter. It isn't good to standardize two fields with similar semantics: doing so raises interoperability concerns as different implementations give different interpretations if both appear. Further confusion is caused by the fact that "X-Priority" appears to be, as the draft notes, a class-of-service indication rather than an end-to-end message importance indicator. But, if there is a need to standardize or recommend some sort of priority field in addition to "Importance:", the standard Internet form should not use an "X-". REMEDY: Either remove these proposed mappings or define real, standards-track, headers, presumably MMS-Message-ID and/or MMS-Priority, for use in this situation. If two Importance/Priority fields are to be recommended (or even not forbidden), specify the semantics when their values are different. (2) RFC 822 defined a syntax for use in address fields when it was desired to not enumerate the recipients, the so-called "Group syntax". That syntax was carried forward into RFC 2822. By contrast, we have generally been careful to avoid assigning semantics to information that appears in comments, or specifying the text or syntax that should appear in such comments, at least unless there are no other possibilities. This specification violates those rules: rather than using the group syntax specified in RFC 2822, it recommends (even if only as a "MAY") that a field containing a comment (but no data) be supplied instead of the group syntax. Interestingly, a reading the syntax productions of RFC 2822 (or RFC 822) indicates that To: (some comment) is equivalent to To: which is not permitted ("To:" requires an address-list) so this recommendation actually violates the standard and is hence not tolerable. In is interesting to note that, while what is done in the MMS environment does not bind what occurs on the Internet side of the gateway, the MMS specification (Section 3.2.1.2 of X.S0016-340-0) provides: In case there are only blind carbon-copy recipient(s) (Bcc:), the behavior shall be as recommended by [RFC2821], Appendix B, i.e. the originating MMS Relay/Server shall only insert an empty Bcc: header and no To: or Cc: headers. The recipient(s) shall then only be indicated in the SMTP command layer (RCPT TO:). So the 3GPP-produced specification conforming to the specifications of RFCs 2821 and 2822 while this proposed gateway specification does not. This is ironic at best. REMEDY: Preferred: Use the group syntax with an empty group. If the LEMONADE WG (or the IESG) are convinced that the "(undisclosed recipients)" comment is an appropriate substitute for the group syntax and should be permitted or encouraged, they should attempt to convince the community of that conclusion via an update to RFC 2822, not by (deliberately or accidentally) concealing the change in this type of document. Alternate 1: Use a "Bcc:" field that is empty or contains only a comment, a form that is permitted by both RFC 822 and RFC 2822. Alternate 2: Do not generate recipient fields. This is permitted by RFC 2822 but not by RFC 822 and is hence probably the least desirable valid option in terms of interoperability. While a case can be made for any of the three choices, the choice made in the document is violation of the existing standards (and their predecessors) and must not be specified without opening and updating those standards. (3) The "contemporary email systems" principle of RFC 2821 is violated. That principle suggests and requires that no new features or capabilities be added to unextended environments (i.e., environments conforming to RFC 821 rather than 2821). The current draft attempts to support the RFC 821 level of specification where possible, and the 2821 level elsewhere. This makes makes the specification far more complex and convoluted than it would be if the mapping that is specified simply required 2821-based gateways. This extra complexity, indeed any excess complexity, is undesirable in an Internet protocol unless it is required by some documented situation or constraint. This document does not contain any evidence of such constraints, nor does there appear to be any evidence of discussion of, much less consensus about, such constraints in the WG email archives. REMEDY: Remove all support for, and discussion of, RFC 821-only email. (4) Under "Sender address" in Section 2.1.3.2 of the specification, there is a fairly convoluted discussion of hidden senders and untrusted relays and receiving servers. Again, this violates a long-standing, although not specifically standardized, principle of Internet mail. Stated simply, if one doesn't trust a relay or any subsequent server in the path (with the understanding that this raises all of the complicated issues about what such "trust" actually means), one should not send the message. This section can be read as attempting to standardize a bad practice. More generally, it is not clear that this document is either a necessary or appropriate place to try to describe or resolve the complex trust issues involved in mail relaying, even though the gateway aspect further complicates those issues. The right solution, actually suggested elsewhere in the document, is to avoid all attempts to support or guarantee hidden senders. REMEDY: See (6), below. (5) Under "Content type" in Section 2.1.3.2 of the specification, reference is made to conversions being done without "significant loss of content". It is not at all clear what "loss of content" means, or how "significant" is to be interpreted. More broadly, there have been extended, and sometimes quite heated, discussions in the community during the last few years about midstream conversions and content alterations of various sorts (discussions about OPES, VPIM, the FAX WG's "CONNEG" features, and ongoing discussions about use of message submission come to mind). Given those discussions, it is quite surprising that the language in this document, which seems to suggest "do whatever you want based on your understanding of what the Internet supports and what you think isn't too damaging", could move through the WG and be accepted by the IESG without comment. At as minimum, this is more evidence that the document was never really reviewed. REMEDY: Perhaps the WG intends "...loss of information" rather than "...loss of content"? "Significant" would still be an issue, but the intent would be considerably more clear. The spirit of the language about gateways in RFC 2821 and general assumptions about desirable practice in the area suggests that this specification should permit no conversions that are not strictly necessary to make the message conform with standards on the side of the gateway to which it is being introduced and should make provision for documenting the conversions that are made. (6) In section 2.1.3.2.2, under "Sender visibility", the specification says "Support for sender address hiding is not included in this version of the mapping document". However, the discussion of "sender address" in 2.1.3.2 specifies how to hide a sender address. At best, this is inconsistent. More generally, invisible sender addresses are an opportunity for spammers, would add to the difficulties of some proposed anti-spam techniques, and are a fairly radical departure from the Internet mail architecture. Not supporting them seems appropriate but, if LEMONADE ever wants to open that door, it should be opened as part of an update to base Internet mail specifications, not through a discussion of syntax in this document. REMEDY: Remove all syntax for sender address hiding and all discussion of the topic other than the current "does not support" text or equivalent. This includes removing the much weaker recommendation, in the security considerations section, that sender identity hiding not be attempted across carrier networks. If it is desired to say anything beyond "does not support", it should be said as part of a clear explanation of why support for this type of option is not practical. (7) In Section 1.3 of the specification, a definition is given for "Gateway Function". With all respect to ongoing efforts to better-define the Internet's email model, there is a fairly extensive definition of gateways and gateway functions in RFC 2821 and the text here is inconsistent with this definition. Going beyond matters of the terminology in this document, the provisions of section 2.1.2 of the specification make use of the term "Relay/Server" inappropriate. If the relevant system does format, media, or transport conversion, it is a Gateway as defined in RFC 2821. REMEDY: As with the group syntax, if the LEMONADE WG believes that current, established, definitions are inadequate, the correct solution is to generate a proposal to update RFC 2821. The definition in this document should either refer to RFC 2821 (or, where applicable, RFC 2822) or be strictly consistent with them. (8) There is an assertion in section 2.1.1 of the specification about the requirements of SMTP with regard to return paths. The assertion in the example is incorrect: SMTP _requires_ null return paths only for error messages involving non-delivery. The extended requirement that null addresses be used for automatically-generated messages occurs elsewhere or are covered by MAY statements or the equivalent in RFC 2821. REMEDY: Correct this reference. (9) This specification provides, in the table of section 2.1.3.1, for a "Resent-Count:" header in Internet mail. This header is not defined in RFC 2822, which is usually assumed to be normative for all "Resent-" headers and their relationships. More important, it violates the important design principle that one should not provide both a list of things that can be counted and the count, lest the two counts disagree. If it is going to do so, text is needed as to what occurs when the number of Resent field sets and the Resent-count differ. Since Resent-count does not appear in 2822, it is reasonable to anticipate that some, probably many, systems will not notice its presence and hence will not update it when the add Resent- fields. It seems completely out of scope for this document unless it really is going to define a "Resent-count:" field (there is no definition at present), but it is not clear how a gateway might calculate such a field given the amount of flexibility in RFC 2822 about which of the Resent- fields may appear and in what combinations. In the general case, if any Resent- fields appear, the value of Resent-count could be reliably bounded only by 1 and the total number of such fields. REMEDY: Drop "Resent-count:" entirely in the absence of compelling need and explanation. If that explanation is provided, it should be explicit about the relationship between the count of Resent field sets and the counter if they happen to differ. It is unlikely that an adequate definition is possible in the absence of an update to RFC 2822 and mechanisms for changing existing deployed practice, so such definition is presumably well outside the scope of the LEMONADE WG. (10) In Section 2.1.3.2.2, there is a subsection titled "Resending/Forwarding" that discusses quoting of message sections and message encapsulation. The quoting mechanism that is discussed has never been standardized because, while there seems to have been some convergence in the last few years, the community has never been able to reach consensus on the subject. The section appears to be completely confused about the relationships among quoting or excerpting and embedding. More important, the encapsulation norm cited, RFC 934, has been generally considered obsolete (even though still widely used) since MIME and its encapsulation mechanisms came into general use. The discussion of that referenced document also appears normative although the reference is listed as informative (see item (14), below. There is also a fairly extensive discussion of forwarding and resending in RFC 2822 and the material in this section does not appear to be completely consistent with it. Similar comments apply to the discussion of Resent- and Received- headers in the next section. This document should cite RFC 2821 or 2822 as appropriate, not try to paraphrase their recommendations (or requirements) and get it even slightly wrong. REMEDY: This document should be rewritten to avoid general discussions and tutorials of aspects of Internet mail that are outside the scope of the specific conversions or mappings being specified. If it is necessary, in the opinion of the WG, to discuss these additional issues, the discussions should confine themselves to agreed-up best practices only or LEMONADE should extend its charter to include discussion and standardization of common, but currently non-standard, practices in Internet mail and then follow up with a document along those lines. (11) In section 2.1.3.3.1 (apparently), there is a discussion of "Sensitivity" that indicates that an "appropriate extended error response code" be used. If this is a protocol specification, it should specify the code(s) to be used or how the implementer should determine such code(s). Without that level of specification, this document is an invitation to interoperability problems. REMEDY: Where codes are intended, they should be specified. (12) In section 3, it is asserted that SMTP Authentication protects against misidentification of message source. SMTP Authentication protects only against misidentification of the most-recent sender and has little to do with message sources except through out of band (whether explicit or implicit) trust chains. REMEDY: Correct this text. (13) The IANA Considerations section, section 4, indicates that no actions are requested of IANA. However, this specification introduces several new headers into the Internet mail environment. Those headers should be registered in the registry specified in RFC 4021. REMEDY: Correctly specify the IANA actions and explicitly identify the new headers. (14) While this document specifies in its introduction that an understanding of the MMS specifications is required to read and understand it, the MMS specifications are all listed as informative, not normative. Even if that text did not appear, the notion of a gateway specification that did not require an understanding of the definitions of the systems on both sides would be, at best, very unusual. "You need to understand that in order to read and implement this" is the very essence of a normative reference. Apparently neither the WG nor the IESG did an adequate review to determine which references were actually normative and which were not. There are fairly well-defined procedures for normative references to the documents of other standards bodies in IETF standards-track specifications; there is no evidence that they have been followed here. The reference to RFC 934 raises an additional issue: that specification's maturity level is listed as "unknown". While RFC 3967 provides a mechanism for referring normatively to documents at a "lower level", it is not clear how, or if, one can refer to a document with status "unknown". Even if RFC 3967 is construed to treat "unknown" as equivalent to the lowest permitted reference level, there is no evidence in the WG archives or the Last Call for this document that the procedures it specifies have been followed here. REMEDY: Get rid of the reference to RFC 934 by cleaning up the material discussed under (10) or, if it is to be retained, clarify its status (presumably requiring an IETF Last Call and probably a new document). Move the MMS references to the "normative" section and make sure that all requirements for references to such documents have been met. (15) In Section 3 (Security Considerations), there is a paragraph that begins "Since MMS does not include a clear separation between in-transit envelope and message content, there are increased risks of unauthorized disclosure of information, and additional challenges in protecting data. For example, Bcc recipients do not normally appear in the message content, only in the envelope; care MUST be taken in...". This is at variance with the current (cited) version of the MMS specification, which appears to specify what should be done in this case very clearly, where it says: In case there are both To: / Cc: and Bcc: recipients, the Bcc: headers shall be removed by the originating MMS Relay/Server and the Bcc: recipients shall only be indicated in the SMTP command level (RCPT TO:). This is in accordance with the functionality recommended by [RFC2821], Appendix B. That statement is not only fairly clear, it is consistent with the specification in RFC 2821, which the document itself is not. Whether a MUST-level requirement should appropriately appear in an example embedded in the middle of the security considerations section is an issue we will leave for the editorial process, but, again, it suggests a lack of adequate review. REMEDY: Since the MMS specification is well-aligned with the requirements of RFC 2821 and 2822, this text and recommendation should be aligned with it. Gateways should make as few conversations, and do as little damage, as possible. (16) There are a number of mapping issues about which the document appears to hand-wave, indicating that something MAY be done but without any specification as to how to do it. The issue is somewhat similar to that of (11), above, but involves fundamental design principles that the document does not address. For example, the document indicates that, if a Message-ID is not present, "...the value of the 'X-Mms-Message-Id:' header MAY be used" to create one. But X-MMS-Message-ID doesn't obey the syntax rules for Message-IDs, so, if traceability is desired, this document needs to specify how the Message-ID mapping is accomplished. If traceability is not important, then the document should probably just indicate that a Message-ID MUST be made up (a requirement of RFC 2822) and that any handy information, including the contents of an X-MMS-Message-ID header if present MAY optionally be used to create it, but that the information will not be useful for tracing messages or their relationships. Similar issues arise with addresses. It is common in the MMS environment for addresses to be E.164-format telephone numbers, without domain names. The MMS specification makes a recommendation about how to handle this but it may or may not be appropriate in all cases. Following precedent in other areas, it may be appropriate is insert the domain of the gateway, thereby making the assumption (faulty in X.400 and faulty here) that forward and reverse paths for these messages across gateways are necessarily equivalent. Note that injecting an address without a fully-qualified domain name into the Internet violates RFC 2821 and RFC 2822. REMEDY: The document needs to be specific about mappings when it is intended that they be useful (e.g., for routing of messages or message tracing or linking) and to be explicit when the mappings are for informal documentation purposes or conformance on one side of the gateway only. If domain names are made up (e.g., by inserting a gateway domain), the document needs to discuss the security and operational implications of doing so. (17) Another paragraph of the Security Considerations section reads: It is possible to hide the sender's identity from non-recipients using anonymous remailers. It is hard to hide the sender's identity from recipients when the mail is cryptographically signed. In view of anti-spam measures it may be undesirable to hide the sender's identity. This borders on the silly, since one can eliminate the particular identity-revealing problem associated with signed mail by simply removing the signature. More important, it is not clear why a general discussion of anonymous remailers and similar tools belongs in this document unless the WG or editor are just trying to tell us how much they know (and the editor in this case knows a great deal more than this). The document repudiates sender-hiding (see (6) above); this is gateway specification should focus on issues associated with the gateway, leaving general issues of anonymity in Internet Mail to other specifications. REMEDY: Remove this text unless there is a substantive reason to include it. If there is, it is going to need significant reworking including, presumably, addressing the case of address hiding or exposure with encrypted message body parts that might contain full RFC 822/ 2822 headers. (18) The listed of bulleted "existing mechanisms" in the Security Considerations section is deeply flawed. As noted in (12) above, SMTP Authentication does not "protect against misidentification of message source", it merely protects against spoofing of the previous-hop server. Anything more requires trust assumptions or agreements about the behavior of that server that are not covered in this document (or in the SMTP AUTH one). The document is correct in stating that IPSEC and SSH or TLS are useful only in protecting against in-transit modification between adjacent servers, but, if it is going to make those statements, it should discuss the limitations of those techniques in an email environment and the particular difficulties associated with them on the two sides of a gateway. To do otherwise appears to be a pretense of security and completeness to pad out the document, one that can be misleading to readers (whether implementers or users). It also recommends use of PGP or S/MIME to protect message contents. This is normally a good recommendation for email, since the techniques work end to end rather than hop-by-hop. However, there is a long history of problems when PGP and S/MIME message privacy and message integrity mechanisms cross gateway boundaries between systems of a rather different character, and it is irresponsibile to recommend those techniques without discussing those potential problems or demonstrating an understanding of them and providing a pointer to the places where they have been discussed (such as RFC 2480). REMEDY: The Security Considerations generally, and this material in particular, should be updated to reflect operational realities and the actual applicability and utility of techniques in a gateway environment. (19) It is possible that this should be viewed as a primarily an editorial comment, but, at this point, we understand how to construct and write a mail gateway specification. RFC 2821 outlines the basic requirements and we have worked examples for even more complex cases than this one, e.g., in RFCs 2156 and 2157 and the documents leading up to them. We start with one protocol and definition as input, figure out which of its components can be mapped accurately to the other side in terms of their semantics, specify those mappings, and then examine the components that cannot be mapped exactly and figure out what should be done about them -- either dropping them or producing the nearest possible semantics on the receiving side while continuing to conform to all of the requirements of the receiving side. The process is then repeated with the sides reversed, and then both sides are reviewed to be sure that any traceability or "reply" considerations are satisfied. It is key to gateway specification models that the document make no assumption that the behavior of client or end systems that receive or send mail that will ultimately pass through the gateway change in any way. If such changes are desired, they must be pursued independently, explicitly, and with due consideration of the likelihood of effective deployment, with the organizations who have change control of the individual systems and protocols that feed into the gateway. Unless those other groups can somehow be expected to be able to instantly make and deply those changes, the gateway specification must be [still] written on the assumption that the changes will not occur or will not be ubiquitious. Obviously those constraints make the job of the gateway-specifier harder, but any other assumption is just not operationally plausible, especially --as is typically the case-- the end systems assume that they are communicating within their own environments rather than through a gateway. This document does not convey the impression that the above model was followed and all of the steps carefully taken. In particular, there are mismatches in semantics and mappings that impact traceability or replies that are not properly accounted for. Some of those are described above. Others involve skimming over serious semantic mismatches between the "Disposition-Notification-To:" header specified in [MDN] and the "X-MMS-Read-Reply" header. "Replacing" one field with the other requires pulling information from elsewhere, and the document provides no guidance as to how to do that. A more systematic analysis along the lines above would, presumably, have at least identified the problem and called for some discussion. Similarly, since the document is not written clearly as a gateway specification --with no assumption that it can change the downstream or upstream environments on either side-- it is muddled about whether the MDNs it describes are generated by the gateway or whether they are generated in the MMS (or Internet mail) environments respectively and then translated by the gateway. That muddle leads to, e.g., a situation in which the specification appears to call for mapping of a Disposition-Notification-To field in an MMS-generated MDN to an Internet message, but that field will not appear in an MMS-environment MDN. REMEDY: Revoke the Protocol Action notice and return this document to the WG, insisting that all of the substantive points above be addressed and that the document not be forwarded back to the IESG until there is evidence of adequate review and consensus about the results. ------------- In several, but certainly not all, of the cases listed above, there would be little basis for appeal if there were evidence that the WG had carefully considered the issues, the tradeoffs, and the possible impact, consulted as needed with others about them, and then arrived at informed conclusions. However, there is little or no evidence of such consideration and deliberation on the part of the WG, at least since version -02 of the relevant document was posted. In other cases, there has been a clear failure of adequate review and justification for changes to the Internet's email fabric and its definitions, changes that go well beyond the agreed-upon scope of the WG. In accepting this document for publication as a standards-track specification, especially after many of the above issues had been pointed out to it, the IESG either failed in its responsibility to determine the existence and adequacy of community consensus or chose to substitute its judgment for that of a largely-silent WG and broader community without making an attempt to raise these issues when them. In either case, the decision to accept this document, in its present form, as a Proposed Standard should be withdrawn and a review and revision process initiated. It is important to stress that this appeal, however lengthy and detailed, is not a comprehensive review of the document and, hence, that "fix the points listed in the appeal" is not an adequate or appropriate remedy. It would be especially inappropriate if that instruction were delivered to the document editor as a matter for negotiation with the IESG. Instead, the details above should be considered as nothing more than a set of examples whose cumulative impact should be to demonstrate that this document should be returned to the WG with instructions to perform the level of analysis, and guarantee the level of review, that should have preceeded submission to the IESG as a WG document. --Apple-Mail-5-542529573 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf --Apple-Mail-5-542529573-- From owner-v6ops@ops.ietf.org Mon Jun 13 05:58:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25398 for ; Mon, 13 Jun 2005 05:58:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhlfL-0002oW-4N for v6ops-data@psg.com; Mon, 13 Jun 2005 09:55:35 +0000 Received: from [131.228.20.94] (helo=mgw-ext02.nokia.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DhlfH-0002nw-TV for v6ops@ops.ietf.org; Mon, 13 Jun 2005 09:55:32 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5D9tSF0004421; Mon, 13 Jun 2005 12:55:28 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jun 2005 12:54:17 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jun 2005 12:54:17 +0300 Received: from 172.21.154.84 ([172.21.154.84]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jun 2005 09:54:15 +0000 Received: from essrv103nok15484.ntc.nokia.com by ESEBE100.noe.nokia.com; 13 Jun 2005 12:54:15 +0300 Subject: Re: WG Last Call draft-ietf-v6ops-nap* From: "Soininen Jonne (Nokia-NET/Helsinki)" To: "ext fred@cisco.com" Cc: v6ops@ops.ietf.org In-Reply-To: <200506061300.j56D0Ui22032@irp-view7.cisco.com> References: <200506061300.j56D0Ui22032@irp-view7.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1118656454.4511.83.camel@essrv103nok15484.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 13 Jun 2005 12:54:15 +0300 X-OriginalArrivalTime: 13 Jun 2005 09:54:17.0772 (UTC) FILETIME=[DD27F6C0:01C56FFD] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I read the document now again and I tried to read it pretty carefully. (It is Monday, so, I'm not sure how careful it was, though. ;) Here are the few comments that I had: 1) Section 2.2: I'm not native English speaker. So, my understanding of some words might be completely wrong. However, I think the phrase "evil outside influences" makes me think about something in horror stories (e.g. Dracula). Would word "malicious" be more appropriate? 2) Section 2.6: The section nicely explains the situation with the IPv4 address space. However, I have recently met misunderstanding of the size of the private address space. There seems to be a belief out there that private address space is limitless. Would it be appropriate to add some words to address this issue as well? (E.g. "Even the use of private (RFC1918) IPv4 address space has its practical limits. Especially, in large network environments the private address space can be exhausted resulting to difficult or even impossible operational problems") I'm not sure, though, if it is appropriate in this particular section. 3) Section 4.4: Usage of Mobile IP is proposed for topology hiding. However, wouldn't any kind of tunneling do the trick? Is there a reason that it really must be Mobile IP. As apparent from the comments, these are basically just nits. I think it is enough it the editors use their judgment if they think these comments are valid or not. I think the document is ready for the IESG. Cheers, Jonne. On Mon, 2005-06-06 at 16:00, ext fred@cisco.com wrote: > Folks > > This note starts the WG Last Call for comments on > > "IPv6 Network Architecture Protection", Gunter Van de Velde, > 28-Mar-05, > > > It may be found on > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-00.txt > > The document's proposed status is Informational. > > Please review the document carefully, and send your feedback to the > list. Please also indicate whether or not you believe that this > document is ready to go to the IESG. > > This Last Call will end two weeks from today at Close of Business PDT. > > Thanks, > > Fred -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Mon Jun 13 06:32:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27511 for ; Mon, 13 Jun 2005 06:32:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhmDg-0006Wr-U8 for v6ops-data@psg.com; Mon, 13 Jun 2005 10:31:04 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DhmDd-0006WR-VL for v6ops@ops.ietf.org; Mon, 13 Jun 2005 10:31:02 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j5DAV0i3005806 for ; Mon, 13 Jun 2005 11:31:00 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA05882 for ; Mon, 13 Jun 2005 11:30:53 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j5DAUra05772 for v6ops@ops.ietf.org; Mon, 13 Jun 2005 11:30:53 +0100 Date: Mon, 13 Jun 2005 11:30:53 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call draft-ietf-v6ops-nap* Message-ID: <20050613103053.GL945@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <200506061300.j56D0Ui22032@irp-view7.cisco.com> <1118656454.4511.83.camel@essrv103nok15484.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1118656454.4511.83.camel@essrv103nok15484.ntc.nokia.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jun 13, 2005 at 12:54:15PM +0300, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > 2) Section 2.6: The section nicely explains the situation with the IPv4 > address space. However, I have recently met misunderstanding of the size > of the private address space. There seems to be a belief out there that > private address space is limitless. > Would it be appropriate to add some words to address this issue as well? > (E.g. "Even the use of private (RFC1918) IPv4 address space has its > practical limits. Especially, in large network environments the private > address space can be exhausted resulting to difficult or even impossible > operational problems") I'm not sure, though, if it is appropriate in > this particular section. Good point. I think this issue should be stressed somewhere. Tim From owner-v6ops@ops.ietf.org Mon Jun 13 06:44:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28315 for ; Mon, 13 Jun 2005 06:44:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhmPj-0007ib-D5 for v6ops-data@psg.com; Mon, 13 Jun 2005 10:43:31 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DhmPh-0007iP-Nu for v6ops@ops.ietf.org; Mon, 13 Jun 2005 10:43:29 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2005 03:43:29 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5DAhMNE016957; Mon, 13 Jun 2005 06:43:26 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 06:43:25 -0400 Received: from 10.86.242.127 ([10.86.242.127]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jun 2005 10:43:25 +0000 Received: from localhost.localdomain by email.cisco.com; 13 Jun 2005 06:43:56 -0400 Subject: Re: WG Last Call draft-ietf-v6ops-nap* From: Ralph Droms To: Tim Chown Cc: v6ops@ops.ietf.org In-Reply-To: <20050613103053.GL945@login.ecs.soton.ac.uk> References: <200506061300.j56D0Ui22032@irp-view7.cisco.com> <1118656454.4511.83.camel@essrv103nok15484.ntc.nokia.com> <20050613103053.GL945@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 13 Jun 2005 06:43:55 -0400 Message-Id: <1118659436.5880.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 13 Jun 2005 10:43:25.0520 (UTC) FILETIME=[BA269D00:01C57004] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2005-06-13 at 11:30 +0100, Tim Chown wrote: > On Mon, Jun 13, 2005 at 12:54:15PM +0300, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > > > 2) Section 2.6: The section nicely explains the situation with the IPv4 > > address space. However, I have recently met misunderstanding of the size > > of the private address space. There seems to be a belief out there that > > private address space is limitless. > > Would it be appropriate to add some words to address this issue as well? > > (E.g. "Even the use of private (RFC1918) IPv4 address space has its > > practical limits. Especially, in large network environments the private > > address space can be exhausted resulting to difficult or even impossible > > operational problems") I'm not sure, though, if it is appropriate in > > this particular section. > > Good point. I think this issue should be stressed somewhere. > > Tim I agree that this is an excellent point. And not just a theoretical point - I understand that some enterprises have exhausted the addresses available in 10.0.0.0/8 and must resort to engineering solutions like internal NAT. - Ralph From owner-v6ops@ops.ietf.org Mon Jun 13 07:30:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01391 for ; Mon, 13 Jun 2005 07:30:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dhn7T-000CLk-HZ for v6ops-data@psg.com; Mon, 13 Jun 2005 11:28:43 +0000 Received: from [209.123.233.211] (helo=smtp-out1.oct.nac.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dhn7R-000CKZ-KX for v6ops@ops.ietf.org; Mon, 13 Jun 2005 11:28:41 +0000 Received: (qmail 64655 invoked by uid 1000); 13 Jun 2005 11:28:34 -0000 Received: from rfgraveman@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.026481 secs); 13 Jun 2005 11:28:34 -0000 Received: from unknown (HELO webmail.nac.net) (64.21.52.85) by smtp-out1.oct.nac.net with SMTP; 13 Jun 2005 11:28:34 -0000 Received: from 67.84.243.204 (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Mon, 13 Jun 2005 07:28:34 -0400 (EDT) Message-ID: <33403.67.84.243.204.1118662114.squirrel@webmail.nac.net> In-Reply-To: <1118656454.4511.83.camel@essrv103nok15484.ntc.nokia.com> References: <200506061300.j56D0Ui22032@irp-view7.cisco.com> <1118656454.4511.83.camel@essrv103nok15484.ntc.nokia.com> Date: Mon, 13 Jun 2005 07:28:34 -0400 (EDT) Subject: Re: WG Last Call draft-ietf-v6ops-nap* From: rfgraveman@nac.net To: "Soininen Jonne (Nokia-NET/Helsinki)" Cc: "ext fred@cisco.com" , v6ops@ops.ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Jonne, > 1) Section 2.2: I'm not native English speaker. So, my understanding of > some words might be completely wrong. However, I think the phrase "evil > outside influences" makes me think about something in horror stories > (e.g. Dracula). Would word "malicious" be more appropriate? Good catch. "Malicious" is better than "evil," but "malicious" has its own unfortunate baggage in *some* parts of the security community, when it is used as the opposite of "passive." (A "malicious" adversary may actively tamper, whereas a "passive" adversary only listens. I always disliked that usage.) I prefer no value judgment at all. Just drop "evil." If absolutely necessary, say "adversary." Who knows, the truly bad people may be "inside," and the good ones are on the "outside" trying to break in. (That is, there may be legitimate disagreement on good and evil.) Regards, Richard From owner-v6ops@ops.ietf.org Wed Jun 15 16:16:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23868 for ; Wed, 15 Jun 2005 16:16:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DieGP-00035k-1Z for v6ops-data@psg.com; Wed, 15 Jun 2005 20:13:29 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DieGO-00035S-4O for v6ops@ops.ietf.org; Wed, 15 Jun 2005 20:13:28 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DieGN-0006vm-6P; Wed, 15 Jun 2005 16:13:27 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-Id: Date: Wed, 15 Jun 2005 16:13:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Network Architecture Protection Author(s) : G. Van de Velde, et al. Filename : draft-ietf-v6ops-nap-01.txt Pages : 31 Date : 2005-6-15 Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-nap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-nap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-15153836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-nap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-nap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-15153836.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 15 16:33:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29657 for ; Wed, 15 Jun 2005 16:33:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DieZ1-0005yX-6Q for v6ops-data@psg.com; Wed, 15 Jun 2005 20:32:43 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DieYz-0005yG-UW for v6ops@ops.ietf.org; Wed, 15 Jun 2005 20:32:41 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2005 13:32:41 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j5FKWdlw011348 for ; Wed, 15 Jun 2005 13:32:40 -0700 (PDT) Received: from [10.32.244.219] (stealth-10-32-244-219.cisco.com [10.32.244.219]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j5FKKFHQ023635 for ; Wed, 15 Jun 2005 13:20:16 -0700 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1101b457ea917d5fc76df64c18d11bb8@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Date: Wed, 15 Jun 2005 13:32:38 -0700 To: "'v6ops@ops.ietf.org '" X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1118866816.260308"; x:"432200"; a:"rsa-sha1"; b:"nofws:4207"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"p7eEq72zZTq0WbE9XuZJDpx61LgDKz3kR5BS6PdW7Ty0QcbyZyZvfcbjpYSdpitMn7PT5m0H" "M9M/QzcegMtMUXxPvEcWow+cDsjjZOdddNEB5QYmV19eJvD3fgRB8rnA5ltk2T1ir2NMXvqyXJc" "jif2Vg50rUJGhGIgokCZqOoU="; c:"From: Fred Baker "; c:"Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt "; c:"Date: Wed, 15 Jun 2005 13:32:38 -0700" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gunter tells me that this draft was almost ready for submission when I issued the last call on the previous version. oops. Let's restart the last call today, reviewing this draft, and ending two weeks from today. On Jun 15, 2005, at 1:13 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : IPv6 Network Architecture Protection > Author(s) : G. Van de Velde, et al. > Filename : draft-ietf-v6ops-nap-01.txt > Pages : 31 > Date : 2005-6-15 > > Although there are many perceived benefits to Network Address > Translation (NAT), its primary benefit of "amplifying" available > address space is not needed in IPv6. In addition to NAT's many > serious disadvantages, there is a perception that other benefits > exist, such as a variety of management and security attributes that > could be useful for an Internet Protocol site. IPv6 does not > support > NAT by design and this document shows how Network Architecture > Protection (NAP) using IPv6 can provide the same or more benefits > without the need for NAT. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-v6ops-nap-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-nap-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ----------------------------------------------------------------------- > -- > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ----------------------------------------------------------------------- > -- > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a > seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j5FKITc4010679 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > > --OtherAccess-- From owner-v6ops@ops.ietf.org Thu Jun 16 03:41:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22431 for ; Thu, 16 Jun 2005 03:41:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dioxk-0007BK-HL for v6ops-data@psg.com; Thu, 16 Jun 2005 07:38:56 +0000 Received: from [131.228.20.96] (helo=mgw-ext04.nokia.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Dioxg-0007Az-NU for v6ops@ops.ietf.org; Thu, 16 Jun 2005 07:38:53 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5G7Yn16009455; Thu, 16 Jun 2005 10:34:53 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jun 2005 10:38:48 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jun 2005 10:38:47 +0300 Received: from 172.21.154.75 ([172.21.154.75]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Jun 2005 07:38:46 +0000 Received: from essrv103nok15475.ntc.nokia.com by ESEBE100.noe.nokia.com; 16 Jun 2005 10:38:46 +0300 Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Fred Baker Cc: "'v6ops@ops.ietf.org '" In-Reply-To: <1101b457ea917d5fc76df64c18d11bb8@cisco.com> References: <1101b457ea917d5fc76df64c18d11bb8@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1118907526.4718.17.camel@essrv103nok15475.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Jun 2005 10:38:46 +0300 X-OriginalArrivalTime: 16 Jun 2005 07:38:47.0293 (UTC) FILETIME=[6E4092D0:01C57246] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I would still do my three comments that I did previously: "1) Section 2.2: I'm not native English speaker. So, my understanding of some words might be completely wrong. However, I think the phrase "evil outside influences" makes me think about something in horror stories (e.g. Dracula). Would word "malicious" be more appropriate? 2) Section 2.6: The section nicely explains the situation with the IPv4 address space. However, I have recently met misunderstanding of the size of the private address space. There seems to be a belief out there that private address space is limitless. Would it be appropriate to add some words to address this issue as well? (E.g. "Even the use of private (RFC1918) IPv4 address space has its practical limits. Especially, in large network environments the private address space can be exhausted resulting to difficult or even impossible operational problems") I'm not sure, though, if it is appropriate in this particular section. 3) Section 4.4: Usage of Mobile IP is proposed for topology hiding. However, wouldn't any kind of tunneling do the trick? Is there a reason that it really must be Mobile IP?" Anyways, despite my nit comments I still think the document is ready for the IESG. Cheers, Jonne. On Wed, 2005-06-15 at 23:32, ext Fred Baker wrote: > Gunter tells me that this draft was almost ready for submission when I > issued the last call on the previous version. oops. Let's restart the > last call today, reviewing this draft, and ending two weeks from today. > > On Jun 15, 2005, at 1:13 PM, Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IPv6 Operations Working Group of the > > IETF. > > > > Title : IPv6 Network Architecture Protection > > Author(s) : G. Van de Velde, et al. > > Filename : draft-ietf-v6ops-nap-01.txt > > Pages : 31 > > Date : 2005-6-15 > > > > Although there are many perceived benefits to Network Address > > Translation (NAT), its primary benefit of "amplifying" available > > address space is not needed in IPv6. In addition to NAT's many > > serious disadvantages, there is a perception that other benefits > > exist, such as a variety of management and security attributes that > > could be useful for an Internet Protocol site. IPv6 does not > > support > > NAT by design and this document shows how Network Architecture > > Protection (NAP) using IPv6 can provide the same or more benefits > > without the need for NAT. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-v6ops-nap-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-v6ops-nap-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > ----------------------------------------------------------------------- > > -- > > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > > ----------------------------------------------------------------------- > > -- > > In order to maintain computing infrastructure integrity, Cisco Systems > > Enterprise Messaging Services and InfoSec teams have set a mail policy > > disallowing executable attachments in email. > > > > This message contained an executable attachment type that is prohibited > > by this policy. The attachment has been removed from this message and > > copied to quarantine by our systems. It will be held in quarantine for > > seven days in the event that the content needs to be retrieved. > > > > Please be aware many viruses attempt to look like legitimate email or > > notifications from anti-virus systems. We will clearly mark a > > seperation > > between our notifications and the original email as follows: > > > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > > > For further reference information about viruses and email antivirus > > efforts within Cisco, please visit: > > > > http://wwwin.cisco.com/it/ems/services/antiviral > > > > If your concern isn't addressed by the information in this notification > > or the above web page, you may open a support request: > > > > http://wwwin.cisco.com/support/ > > > > Select "Messaging", "Email-Related", "Mail Routing" > > > > Please include in the text of your case the following information: > > > > * Full headers of the message. Documentation on displaying the full > > headers is available at this URL: > > > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > > > * This unique quarantine identifier: j5FKITc4010679 > > > > If the matter is urgent, you may follow up by calling one of the below > > referenced numbers. Please make every effort to provide the above > > requested information via the support web tool prior to calling as it > > will greatly aid the resolution of your issue. > > > > Americas: > > 1 408 526 8888 > > > > Asiapac > > +61 2 8446 8888 > > > > EMEA > > +31 20 485 4888 > > > > Japan > > +81 3 5549 6888 > > > > US (Toll Free) > > 1| 800| 888| 8187| (ext.68888) > > > > Thank you for your cooperation, > > > > Enterprise Messaging Services > > Cisco Systems, Inc > > > > --OtherAccess-- -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Jun 16 12:34:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08689 for ; Thu, 16 Jun 2005 12:34:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DixHa-000PQ2-AT for v6ops-data@psg.com; Thu, 16 Jun 2005 16:31:58 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DixHX-000PPT-Td for v6ops@ops.ietf.org; Thu, 16 Jun 2005 16:31:56 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA04205; Thu, 16 Jun 2005 09:31:55 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5GGVtn06109; Thu, 16 Jun 2005 09:31:55 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Jun 2005 09:31:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-v6ops-nap-01.txt Date: Thu, 16 Jun 2005 09:31:58 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4ED1@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: I-D ACTION:draft-ietf-v6ops-nap-01.txt Thread-Index: AcVx740PNabyk0dNSNqJ3gOzMzWAwwAm8/SA From: "Templin, Fred L" To: "Fred Baker" , X-OriginalArrivalTime: 16 Jun 2005 16:31:53.0938 (UTC) FILETIME=[E7C74320:01C57290] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Fred - here are my comments on nap-01: 1) P.4, last sentence of next-to-last paragraph, change: "without = address translation" to : "without IPv6 address translation". 2) P.8, last sentence of next-to-last paragraph, punctuation at end of = sentence. 3) P.14, paragraph beginning: "This simple rule...". The first sentence = in this paragraph is overly-long and I had trouble parsing it. The = sentence should at least be subdivided with some attention to grammar. Also, I am not sure about the assertion: "similar protection and = security holes the typical IPv4 NAT device will offer" since the example = firewall rules above speak of creating reflective (symmetric?) session = state. If, by reflective session state, it means that the rule for = inbound traffic will be identical to the rule for outbound traffic = except with the source and destination portions reversed, then my = understanding from other documents I have read is that this is not how = the typical IPv4 NAT device works. (From what I have read, I have been = led to believe that the typical IPv4 NAT device leaves some/all of the = source portion for inbound traffic rules as wildcard match.) I hope that reflective/symmetric is how it will work for NAP, since I = have some concerns for security with the typical IPv4 NAT's wildcard = match. 4) P. 15, last paragraph, change: "so that a NAT is not required" to: = "so that IPv6 address translation is not required". =20 5) P. 16, second paragraph, change: "2^64 hosts" to: "2^64 addresses". I = may have missed other examples throughout the document where "hosts" was = used when "addresses" was intended. 6) P. 22, last paragaph, sentence beginning: "It should not even = try...". This was another overly-long sentence that I found difficult to = parse. (My time to review the document was limited, and I did not have the = chance to review the appendix sections.) Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, June 15, 2005 1:33 PM > To: 'v6ops@ops.ietf.org ' > Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt=20 >=20 >=20 > Gunter tells me that this draft was almost ready for=20 > submission when I =20 > issued the last call on the previous version. oops. Let's=20 > restart the =20 > last call today, reviewing this draft, and ending two weeks=20 > from today. >=20 > On Jun 15, 2005, at 1:13 PM, Internet-Drafts@ietf.org wrote: >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts =20 > > directories. > > This draft is a work item of the IPv6 Operations Working=20 > Group of the =20 > > IETF. > > > > Title : IPv6 Network Architecture Protection > > Author(s) : G. Van de Velde, et al. > > Filename : draft-ietf-v6ops-nap-01.txt > > Pages : 31 > > Date : 2005-6-15 > > =09 > > Although there are many perceived benefits to Network Address > > Translation (NAT), its primary benefit of "amplifying" available > > address space is not needed in IPv6. In addition to NAT's many > > serious disadvantages, there is a perception that other benefits > > exist, such as a variety of management and security=20 > attributes that > > could be useful for an Internet Protocol site. IPv6 does not =20 > > support > > NAT by design and this document shows how Network Architecture > > Protection (NAP) using IPv6 can provide the same or more benefits > > without the need for NAT. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of =20 > > the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login=20 > with the =20 > > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-v6ops-nap-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-v6ops-nap-01.txt". > > =09 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > >=20 > -------------------------------------------------------------- > ---------=20 > > -- > > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > >=20 > -------------------------------------------------------------- > ---------=20 > > -- > > In order to maintain computing infrastructure integrity,=20 > Cisco Systems > > Enterprise Messaging Services and InfoSec teams have set a=20 > mail policy > > disallowing executable attachments in email. > > > > This message contained an executable attachment type that=20 > is prohibited > > by this policy. The attachment has been removed from this=20 > message and > > copied to quarantine by our systems. It will be held in=20 > quarantine for > > seven days in the event that the content needs to be retrieved. > > > > Please be aware many viruses attempt to look like=20 > legitimate email or > > notifications from anti-virus systems. We will clearly mark a =20 > > seperation > > between our notifications and the original email as follows: > > > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION=20 > TECHNOLOGY" > > > > For further reference information about viruses and email antivirus > > efforts within Cisco, please visit: > > > > http://wwwin.cisco.com/it/ems/services/antiviral > > > > If your concern isn't addressed by the information in this=20 > notification > > or the above web page, you may open a support request: > > > > http://wwwin.cisco.com/support/ > > > > Select "Messaging", "Email-Related", "Mail Routing" > > > > Please include in the text of your case the following information: > > > > * Full headers of the message. Documentation on displaying the full > > headers is available at this URL: > > > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > > > * This unique quarantine identifier: j5FKITc4010679 > > > > If the matter is urgent, you may follow up by calling one=20 > of the below > > referenced numbers. Please make every effort to provide the above > > requested information via the support web tool prior to=20 > calling as it > > will greatly aid the resolution of your issue. > > > > Americas: > > 1 408 526 8888 > > > > Asiapac > > +61 2 8446 8888 > > > > EMEA > > +31 20 485 4888 > > > > Japan > > +81 3 5549 6888 > > > > US (Toll Free) > > 1| 800| 888| 8187| (ext.68888) > > > > Thank you for your cooperation, > > > > Enterprise Messaging Services > > Cisco Systems, Inc > > > > --OtherAccess-- >=20 >=20 From 6an-jen@access.mountain.net Thu Jun 16 18:39:11 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22499 for ; Thu, 16 Jun 2005 18:39:11 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj3O3-0004Oa-1o for v6ops-archive@ietf.org; Thu, 16 Jun 2005 19:03:03 -0400 Received: from aaubervilliers-153-1-46-223.w83-200.abo.wanadoo.fr ([83.200.78.223]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dj30w-0001Q1-Lh for v6ops-archive@ietf.org; Thu, 16 Jun 2005 18:39:12 -0400 Message-ID: From: "Richard K. Lee" <6an-jen@access.mountain.net> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?TG92ZSBwaWxscyAtICQyLjk5L2Rvc2U=?= Date: Thu, 16 Jun 2005 22:28:07 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_9CDCF79E.C35CF56A" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_9CDCF79E.C35CF56A Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_F1EBD592.CC624351" ------=_NextPart_001_0001_F1EBD592.CC624351 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Excellent erection Prolonged effect No prescription required 2 popular medicines: CIALIS - http://www.pillsofdesire.com/sv/ VIAGRA - http://www.pillsofdesire.com/vt/ Delivered in a discreet package _________________________________________________________________________ To change your mail details, go here _________________________________________________________________________ ------=_NextPart_001_0001_F1EBD592.CC624351 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Excellent erection
Prolonged effect
No prescription required

2 popular medicines:
CIALIS - http://www.pillsofdesire.com/sv/
VIAGRA - http://www.pillsofdesire.com/vt/

Delivered in a discreet package


_________________________________________________________________________
To change your mail details, go here
_________________________________________________________________________

------=_NextPart_001_0001_F1EBD592.CC624351-- ------=_NextPart_000_0000_9CDCF79E.C35CF56A-- From owner-v6ops@ops.ietf.org Fri Jun 17 03:44:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21159 for ; Fri, 17 Jun 2005 03:44:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DjBT5-000AHN-Kl for v6ops-data@psg.com; Fri, 17 Jun 2005 07:40:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DjBT2-000AGB-Ta for v6ops@ops.ietf.org; Fri, 17 Jun 2005 07:40:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j5H7eeh27127 for ; Fri, 17 Jun 2005 10:40:40 +0300 Date: Fri, 17 Jun 2005 10:40:40 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: WG Last Call draft-ietf-v6ops-bb-deployment-scenarios* In-Reply-To: <200506061300.j56D0TA21968@irp-view7.cisco.com> Message-ID: References: <200506061300.j56D0TA21968@irp-view7.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 6 Jun 2005 fred@cisco.com wrote: > This note starts the WG Last Call for comments on > > "ISP IPv6 Deployment Scenarios in Broadband Access Networks", Salman > Asadullah, 31-May-05, > I did not read the document carefully, because I've already read it many times. However, I think there are still a couple of (relatively minor) issues which require one revision. However, I'd like to keep it at one, and try to get this out for IESG evaluation before Paris IETF, so we could discuss comments (if any) before then. substantial ----------- ==> There have been at least a couple of recent scientific papers describing some shortcomings in IPv6 BB deployment. I don't think these are available in the web, or are very credible, but I think the authors need to read them and understand why the people felt that there was a shortcoming (and proposed their own fixes). While some of these may be true, most are probably not -- those which are not could probably be more clearly described in this document so we can point folks here. I'll send a couple of pointers off-list. ==> during the 01 -> 02 revision, acknowledgements and contributors sections went missing, please restore these. If there is no Customer Router all the hosts on the subscriber site belong to the same /64 subnet that is statically configured on the Edge Router for that subscriber PVC. The hosts can use stateless autoconfiguration or stateful DHCPv6 based configuration to acquire an address via the Edge Router. .... (In gap analysis) This approach changes the provisioning methodologies that were used for IPv4. Static configuration of the IPv6 addresses for all these links on the Edge Routers or Access Routers might not be a scalable option. New provisioning mechanisms or features might need to be developed in order to deal with this issue. ==> this is related to the point I was making earlier, but I think it should still be made much more explicit. How about rewording: If there is no Customer Router all the hosts on the subscriber site belong to the same /64 subnet that may be statically configured on the Edge Router for that subscriber PVC. The hosts can use stateless autoconfiguration or stateful DHCPv6 based configuration to acquire an address via the Edge Router. However, as manual configuration for each customer is a provisioning challenge, implementations are encouraged to develop mechanism(s) which automatically map the VLAN (or some other customer-specific information) to an IPv6 subnet prefix, and advertise the customer-specific prefix to all the customers with minimal configuration. (and something similar in the gap analysis.) ... 10.2 Deploying IPv6 in IPv4 PLC/BPL The most simplistic and efficient model, considering the nature of the PLC/BPL networks, is to see the network as a point-to-point one to each customer. Even if several customers share the same physical media, the traffic is not visible among them because each one uses different channels, which are in addition encrypted by means of 3DES. Furthermore, if required, VLANs could also be used, as already described for the Ethernet case. ==> PLC sections do not describe at all how IPv4 is done (compare to the other sections). Does it use PPP (which variant)? Something like xDSL/Ethernet point-to-point models (which variant)? For consistency and better understand how PLC works, this should be included. ==> You mention VLANs, but while VLANs are well defined for Ethernet, I'm not sure what PLC VLANs are? Maybe PLC is emulating Ethernet the same way that 802.11 is, but the document just isn't clear enough about this? B. Currently the DHCP-PD functionality cannot be implemented if the DHCP-PD server is not the Edge Router. If the DHCP-PD messages are relayed, the Edge Router does not have a mechanism to learn the assigned prefixes and thus install the proper routes to make that prefix reachable. [...] ==> shouldn't you say something like "the first router outside of the customer premises" instead of Edge Router? (or something a bit more compact.) As it is, at least in PLC and also in other technologies, what you call "Edge Router" is not necessarily the CPE's next-hop (in PLC, it seems to be the head-end), and DHCPv6-PD has to be done at that next-hop, right? ..... semi-editorial -------------- If the end customer receives a private IPv4 address and needs to initiate a tunnel through NAT, techniques like 6to4 may not work since they rely on Public IPv4 address. In this case, unless the existing CPE supports protocol-41-forwarding, the end user might have to use tunnels that can operate through NATs (such as Teredo tunnel [30]). The customer has the option to initiate the tunnel from the device (GWR) that performs the NAT functionality, similar to the GWR scenario discussed in section 5.1. This will imply HW replacement or SW upgrade and a native IPv6 environment behind the GWR. Most GWRs support protocol-41-forwarding which means that hosts can initiate the tunnels in which case the GWR is not affected by the IPv6 service. ==> you should provide a reference to protocol-41-forwarding. ==> The last sentence of the second paragraph seems badly placed (and worded). The second paragraph seems to be about GWR v6 support, while the first paragraph is about host tunneling; the sentence should be moved and reworded to the first paragraph. In inter-domain deployments, Multicast Source Discovery Protocol (MSDP) [22] is an important element of IPv4 PIM-SM deployments. MSDP is meant to be a solution for the exchange of source registration information between RPs in different domains. This solution was intended to be temporary. This is one of the reasons why it was decided not to implement MSDP in IPv6 [32]. For multicast reachability across domains, Embedded RP could be used. Despite its shortcomings, MSDP provides additional flexibility in managing the domains that may not be matched with the protocols available in IPv6 today. The value of such flexibility is still under evaluation. ==> I'd maybe reword the latter paragraph to be more positive, because there is not going to be MSDP for v6 (and IMHO there is no use portraying MSDP in a light which might result in the ISPs start asking for it), e.g.: For multicast reachability across domains, Embedded RP can be used. As Embedded RP provides roughtly the equal capabilities but in a slightly different way, the best management practices for ASM multicast with embedded RP still remain to be developed. .... While deploying IPv6 in the above mentioned WLAN architecture, there are three possible scenarios as discussed below. A. Layer 2 Switch Between AP and Edge Router B. Access Router Between AP and Edge Router ==> these options are not exclusive and could possibly be worded a bit better; the critical thing here seems to be where the customer's traffic is terminated at L3. In A, it's at Service Provider; In B, it's at Access Provider. (For example, you can certainly deploy L2 switches in B before the access router :) Just for information/clarification, often the PLC/BPL access networks use hybrid layer 2 combinations either with PLC/BPL in the medium voltage, point to point links, wireless links, satellite, etc., but once more, this seems to be out of the scope of this document, as those means are transparent, for the purpose of this document, to the last half mile access network deployed with PLC/BPL. ==> I'm having difficulty understanding the relevance of this paragraph. Remove or reword? 10.2.1 IPv6 Related Infrastructure Changes In this scenario the RPT is layer 3 unaware, but not the Head End, which should be upgraded to support IPv6. Similarly other devices which have to be upgraded to dual stack: Hosts, RCPE and Edge Router. ==> just say something like: In this scenario only the RPT is layer 3 unaware, but the other devices have to be upgraded to dual stack: Hosts, RCPE, Head End, and Edge Router. 10.2.3 Routing If no routers are used on the custmer premises, the HE can simply be configured with a default route that points to the Edge Router. If a router is used on the customer premises (RCPE) then the HE will run an IGP to the ER such as OSPFv3, IS-IS or even RIPng. [...] ==> whether or not there is RCPE seems independent of whether HE should run a routing protocol towards ER? Assuming all the customers at HE would come from the same aggregate route, static routing between HE and ER could work just fine, even if there were RCPE(s). (Obviously, this doesn't scale well if all the customer prefixes would need to be statically routed, but I don't think it's exactly as black & white as the sentence seems to state.) 10.6 IPv6 Network Management There are no differences in terms of network management if compared with the already described Ethernet case. ==> are you sure? In ethernet case, we have well-defined MIBs. Do the same MIBs exist in PLC equipment as well? Do the different PLC setups require different kind of MIBs? [5] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. ==> this could probably be replaced with [30], because mech-v2 is already in RFC-ed queue. editorial --------- Note: there have been dozens of typos introduced between -00 and -02; most of these can be reasonably easily spotted if you run the docs through 'wdiff' (for example, in section 1, "ISP" changed to "IP".) I've not tried to list these here. - in the abstract, "for completion purposes" -> "for completeness" - in the abstract, there are a lot of abbreviated terms which either need to be spelled out or removed. IMHO, we don't need to list all of these in the abstract; for example, just mention DSL, ethernet and cable as examples of BB technologies covered. - in section 4.2, s/Layer3/Layer 3/ - in section 4.2, make "RFC4029" a reference. - in section 5.1, there were a number of abbreviated terms like NAP, SP, GWR, etc. These should be spelled out. I'd suggest including a very short "common terminology" subsectin 1.1, where you spell these out in one line per each. - in section 5.1 and elsewhere, you've used [[2], [3]] when using multiple references; please use normal ()'s instead, e.g., ([2], [3]) - in section 5.1 and 5.2, s/Tunnels-Customers/Tunnels - Customers/ - in section 5.2, s/Public/public/ - in section 5.2, create an explicit reference for [Tunnel through IPsec] - in section 9.1, s/IEEE 802.11a offers/IEEE 802.11a/g offer/ - in section 10.1, Head End (HE): It is the router that connects the PLC/BPL access network (the power grid), ==> remove "It is" (from here and subsequent terms) to be better in line with the style of the rest of the document? - in section 10.1, "Often is a bridge" -> "It is often a bridge" - in figure 10.1, just replace "HE" with head end (it's short enough) ? - in section 10.2.3, s/custmer/customer/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jun 17 04:52:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25670 for ; Fri, 17 Jun 2005 04:52:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DjCYa-000F6i-PH for v6ops-data@psg.com; Fri, 17 Jun 2005 08:50:32 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DjCYZ-000F6I-8D for v6ops@ops.ietf.org; Fri, 17 Jun 2005 08:50:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j5H8mP128993; Fri, 17 Jun 2005 11:48:26 +0300 Date: Fri, 17 Jun 2005 11:48:25 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: "'v6ops@ops.ietf.org '" Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt In-Reply-To: <1101b457ea917d5fc76df64c18d11bb8@cisco.com> Message-ID: References: <1101b457ea917d5fc76df64c18d11bb8@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 15 Jun 2005, Fred Baker wrote: > Gunter tells me that this draft was almost ready for submission when I issued > the last call on the previous version. oops. Let's restart the last call > today, reviewing this draft, and ending two weeks from today. As Jonne was mentioning (and I've stated this in the past, but not as clearly as he did), I think the MIPv6 tunnels for topology hiding should be rephrased slightly to make it just an example of a tunneling mechanism for topology hiding. As he said, any tunneling is just fine. At the moment, something different is possibly easier to provide; in the future, if MIPv6 provisioning methods improve, maybe it gets more popular (and easier). I think the doc is in a pretty good shape, and after a quick update, ready to go forward. As a procedural point, it might be courteous to ask for external review from NAT communities (e.g., behave WG chairs, [dare I say this] Keith Moore, maybe some others) to make sure the technical content of the document is OK, because this won't be IETF last called. substantial ----------- When IPv6 NAP is utilized in these three domains then for the first category it will be possible to use the same solutions as described in chapter 5.1. The second domain of the ISP/carrier is the Operations network. This environment tends to be a closed environment, and consequently intra- communication can be done based on ULA addresses. This would give a stable configuration with respect to a local IPv6 address plan. Using these local scope addresses would also prevent from being accessed from the external network. ==> For ISP/carrier grade, they already have very stable addresses, so they don't need ULAs for PI purposes. I also think the ISP/carriers should be qualified enough to set up proper filtering, so "prevent from being accessed" doesn't seem like a winning argument either. So, I'd remove the case for ULA for ISP/carrier backbones completely. ... 6. IPv6 gap analysis ==> this section needs major updates. Specifically, 'Completion of work on ULAs' needs to be removed or seriously reworded (the work is finished already). Similarly, as the renumerbing procedure is already also in RFC ed-queue, section 6.4 requires a bit of new phrasing as well. Further, untraceable addresses seem to be discussed in sections 6.2, 6.3 and 6.6; the text should be made more focused. Lastly, in 6.3, I'd say "topology masking _may be_ required" instead of "is required", because whether this is needed or not is a value judgment (which I don't encourage myself, but can live with). semi-editorial -------------- 2.2 Simple security due to stateful filter implementation A firewall doesn't fully secure a network, because many attacks come from inside or are at a layer higher than the firewall can protect against. In the final analysis, every system has to be responsible for its own security, and every process running on a system has to be robust in the face of challenges like stack overflows etc. What a firewall does is prevent a network administration from having to pay for bandwidth to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary. A distributed security mechanism to protect the end-systems may help in the above situation; however, to deploy such a system is quite complex and may depend upon behaviour per operating system and release version. As a result it will probably not be available in the next couple of years for end-user organizations. End-system-only security mechanisms don't protect the network infrastructure from being misused for transit, or against DDOS attacks against individual systems inside, and this is the area where a NAT device is perceived to provide some relief. ==> these _exact_ same paragraphs appear at the start of section 2.4 as well? I suggest removing duplicate text from 2.4 as these issues don't have much to do with 2.4 (privacy & topology hiding) 3. The size of the typical subnet ::/64 will make a network ping sweep and resulting port-scan virtually impossible due to the amount of possible combinations available. This goes from the assumption that the attacker has no access to a local connection. If an attacker has local access then he could use ND [3] and ping6 to ff02::1 to detect local neighbors. (Of course, a locally connected attacker has many scanning options with IPv4 as well.) It is recommended for site administrators to take [17] into consideration to achieve the expected goal. [...] Assuming the network administrator is aware of [17] the increased size of the IPv6 address will make topology probing much harder, and almost impossible for IPv6 devices. What one does when topology probing is to get an idea of the available hosts inside an enterprise. This mostly starts with a ping-sweep. This is an automated procedure of sending Internet Control Message Protocol (ICMP) echo requests (also known as PINGs) to a range of IP addresses and recording replies. This can enable an attacker to map the network. Since the IPv6 subnets are 64 bits worth of address space, this means that an attacker has to send out a simply unrealistic number of pings to map the network, and virus/worm propagation will be thwarted in the process. At full rate 40Gbps (400 times the typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it takes over 5000 years to scan a single 64 bit space. ==> There seemed to be some amount of text duplication about ping sweeping, and it seems a bit illogical to have it described at more length after it has already been introduced? 5. Case Studies It is possible to divide the type of networks in different categories. This can be done on various criteria. The criteria used within this document are based on the number of components or connections. [...] ==> clarify what you mean by 'connections'. For different peoples at different ISO layers it means completely different things. editorial --------- Wide-scale deployments have shown that using NAT to attach a private IPv4 network to the Internet is simple and practical for the non- technical end user. Frequently a simple user interface is sufficient for configuring both device and application access rights. ==> even more frequently, the users don't configure these boxes at all..? Van de Velde, et al. Expires December 3, 2005 [Page 6] L Internet-Draft IPv6 Network Architecture Protection june 2005 ==> s/june/June/ For these reasons the sense of security provided by NAT are actually false. ==> s/are/is/ Once a list of available devices and IP addresses has been mapped, a port-scan on these IP addresses can be performed. Scanning works by tracking which ports do not receive unreachable errors from either the firewall or host. ==> s/unreachable/ICMP unreachable/ or was the wording specifically chosen this way (to a degree also including TCP RST's and such) ? The random assignment has as purpose to confuse the outside world on ==> s/as/a/ 4.1 Simple gateway between Internet and internal network ==> please reorganize this one long paragraph to 2-3 shorter ones. The ongoing subnet size maintenance may become simpler when IPv6 technology is utilised. If IPv4 address space is optimised one has periodically to look into the number of hosts on a segment and the subnet size allocated to the segment; ==> s/periodically to look/to look periodically/ can be concatenated. A single /48 alloaction provides an enterprise ==> s/alloac/alloca/ This means that the ISP will provide the enterprise with an IPv6 address-range (typically a one or multiple range(s) of '/48') from its RIR assigned IPv6 address-space. The goal of this allocation mechanism is to decrease the total amount of entries in the internet routing table. ==> remove one word from "a one" ==> s/allocation/assignment/ IPv6 internet, then some form of 'Untraceable' addresses may be used. ==> s/Untraceable/untraceable/ Operations network. This environment tends to be a closed environment, and consequently intra- communication can be done based on ULA addresses. ==> intra- [what?] communication? From owner-v6ops@ops.ietf.org Fri Jun 17 11:51:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29011 for ; Fri, 17 Jun 2005 11:51:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DjJ5O-000Jrq-BC for v6ops-data@psg.com; Fri, 17 Jun 2005 15:48:50 +0000 Received: from [210.84.230.241] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DjJ5M-000JrN-9H for v6ops@ops.ietf.org; Fri, 17 Jun 2005 15:48:49 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 5BB9C62AAE; Sat, 18 Jun 2005 01:18:43 +0930 (CST) Date: Sat, 18 Jun 2005 01:18:42 +0930 From: Mark Smith To: gunter@cisco.com Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-Id: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, "6.2 Subnet topology masking There really is no functional gap here as a centrally assigned pool of addresses in combination with host routes in the IGP is an effective way to mask topology. " I'm wondering if the above is actually the case. I think host routes are easy enough to understand from the point of view of propagating /128s around within an IGP. What I'm curious about is how the end-nodes are configured and how they operate, in particular when they are attached to a broadcast multi-access link e.g., an ethernet. Has this operation been discussed or described in an ID or RFC that I'm not aware of ? For example, assuming a single IPv6 address assignment (excluding link-local), if an end-node is attached to an ethernet, what prefix length is configured for the address that is going to be used as a host route within the IGP ? I think a /128 would make sense, which means that this end-node would then (initially) consider all IPv6 destinations to be offlink, excepting link-local destinations. The first hop would always be to one or more of the routers it has learned of via RAs. I'd guess that when this host tries to send traffic to other IPv6 devices attached to the same (layer 2) link, the router would then issue an ICMP redirect, irrespective of whether those other devices are also /128 host routed, or more conventionally using /64 prefix lengths, so that this /128 host could communicate directly "onlink" via layer 2 to an IPv6 "offlink" device. Where this possibly gets interesting is for /128 end-nodes, where do they send a link scoped multicast ? Do they send it only to the routers they are aware of ? From an IPv6 routing point of view, I'd think that other than the routers, all other devices would be offlink, because the prefix length is 128 bits, so those other devices shouldn't receive a link-scoped multicast from these /128 end-nodes. Does that mean that these /128 hosts have to layer 2 unicast these IPv6 multicasts to the visible routers, to ensure that the other nodes attached to the link don't see the link-scoped multicast ? Another option could be to assign a really short mask to the address e.g., for a global address in the 2000::/3 address space, the interface prefix length would be /3. The node would then consider all devices to be onlink. For this to work, the router's attached to the link could then perform proxy-ND for all offlink destinations. It sort of solves the link-scope multicast issue, although it means that link-scoped multicasts now have to be forwarded through the cloud to all links that have /128 host routed hosts on them. I haven't read the ND Proxy draft yet, I'll presume for the moment that this issue is considered. All of the above is based on the scenario where a device only has a link-local and a "host routed" address assigned to it's interface, using either a /128 or /3 (for global) prefix length. Another couple of scenarios come to mind which might make things a bit more complicated. (a) These host routed devices are assigned /64s for the ULA address space and (b) for simplicity, at the cost of doubling the number of /128 routes, the ULA addresses are also host routed. I'd also wonder if and how RAs can be used to supply the /128 or /3 addresses. It doesn't seem that the Prefix Information option would support providing only 64 bits of prefix, to be combined with a 64 bit IID, in the case of a global address, to come up with a node address, yet have then host use a /128 or /3 prefix length on the interface to indicate on or offlink destinations. Maybe a "prefix length to use" option would need to be added. ND Proxy solution might be another alternative that could be suggested in this ID, as it effectively hides the structure of the links from external parties. I need to do some research into these issues, which I'll do tomorrow. It's 1:10 here in .au, and I'll be going to bed soon. I appologise if these issues are addressed in an RFC or ID I should have read. If it is convenient, a URL or two would be useful if they exist. If these issues aren't described or solved somewhere, I wonder whether this ID should be recommending host routes as the somewhat preferred solution to topology hiding ? Regards, Mark. PS. sorry for the length, it got away from me a bit, thanks for reading this far. From owner-v6ops@ops.ietf.org Wed Jun 22 14:48:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15825 for ; Wed, 22 Jun 2005 14:48:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlADF-0004IN-G0 for v6ops-data@psg.com; Wed, 22 Jun 2005 18:44:37 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DlADC-0004Hz-Vz for v6ops@ops.ietf.org; Wed, 22 Jun 2005 18:44:35 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Jun 2005 11:44:34 -0700 X-IronPort-AV: i="3.93,221,1115017200"; d="scan'208,217"; a="281860234:sNHT76355586" Received: from sasad-w2k01.cisco.com (sjc-vpn5-19.cisco.com [10.21.88.19]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5MIiTvN015103; Wed, 22 Jun 2005 11:44:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20050622114041.02ee68b0@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Jun 2005 11:44:31 -0700 To: Pekka Savola From: Salman Asadullah Subject: Re: WG Last Call draft-ietf-v6ops-bb-deployment-scenarios* Cc: v6ops@ops.ietf.org In-Reply-To: References: <200506061300.j56D0TA21968@irp-view7.cisco.com> <200506061300.j56D0TA21968@irp-view7.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3867481==_.ALT" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_3867481==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks for the comments Pekka. We'll address the comments and get in touch with you offline if needed. Please send those couple of pointers you mentioned, to us. Regards, Salman At 10:40 AM 6/17/2005 +0300, Pekka Savola wrote: >On Mon, 6 Jun 2005 fred@cisco.com wrote: >>This note starts the WG Last Call for comments on >> >> "ISP IPv6 Deployment Scenarios in Broadband Access Networks", Salman >> Asadullah, 31-May-05, >> > >I did not read the document carefully, because I've already read it many >times. However, I think there are still a couple of (relatively minor) >issues which require one revision. However, I'd like to keep it at one, >and try to get this out for IESG evaluation before Paris IETF, so we could >discuss comments (if any) before then. > >substantial >----------- > >==> There have been at least a couple of recent scientific papers >describing some shortcomings in IPv6 BB deployment. I don't think these >are available in the web, or are very credible, but I think the authors >need to read them and understand why the people felt that there was a >shortcoming (and proposed their own fixes). While some of these may be >true, most are probably not -- those which are not could probably be more >clearly described in this document so we can point folks here. I'll send a >couple of pointers off-list. > >==> during the 01 -> 02 revision, acknowledgements and contributors >sections went missing, please restore these. > > > If there is no Customer Router all the hosts on the subscriber site > belong to the same /64 subnet that is statically configured on the > Edge Router for that subscriber PVC. The hosts can use stateless > autoconfiguration or stateful DHCPv6 based configuration to acquire > an address via the Edge Router. >.... >(In gap analysis) > This approach changes the provisioning methodologies that were used > for IPv4. Static configuration of the IPv6 addresses for all these > links on the Edge Routers or Access Routers might not be a scalable > option. New provisioning mechanisms or features might need to be > developed in order to deal with this issue. > >==> this is related to the point I was making earlier, but I think it >should still be made much more explicit. How about rewording: > > If there is no Customer Router all the hosts on the subscriber site > belong to the same /64 subnet that may be statically configured on the > Edge Router for that subscriber PVC. The hosts can use stateless > autoconfiguration or stateful DHCPv6 based configuration to acquire > an address via the Edge Router. > > However, as manual configuration for each customer is a provisioning > challenge, implementations are encouraged to develop mechanism(s) which > automatically map the VLAN (or some other customer-specific information) > to an IPv6 subnet prefix, and advertise the customer-specific prefix > to all the customers with minimal configuration. > >(and something similar in the gap analysis.) > >... > >10.2 Deploying IPv6 in IPv4 PLC/BPL > > The most simplistic and efficient model, considering the nature of > the PLC/BPL networks, is to see the network as a point-to-point one > to each customer. Even if several customers share the same physical > media, the traffic is not visible among them because each one uses > different channels, which are in addition encrypted by means of 3DES. > > Furthermore, if required, VLANs could also be used, as already > described for the Ethernet case. > >==> PLC sections do not describe at all how IPv4 is done (compare to the >other sections). Does it use PPP (which variant)? Something like >xDSL/Ethernet point-to-point models (which variant)? For consistency and >better understand how PLC works, this should be included. > >==> You mention VLANs, but while VLANs are well defined for Ethernet, I'm >not sure what PLC VLANs are? Maybe PLC is emulating Ethernet the same way >that 802.11 is, but the document just isn't clear enough about this? > > B. Currently the DHCP-PD functionality cannot be implemented if the > DHCP-PD server is not the Edge Router. If the DHCP-PD messages are > relayed, the Edge Router does not have a mechanism to learn the > assigned prefixes and thus install the proper routes to make that > prefix reachable. [...] > >==> shouldn't you say something like "the first router outside of the >customer premises" instead of Edge Router? (or something a bit more >compact.) As it is, at least in PLC and also in other technologies, what >you call "Edge Router" is not necessarily the CPE's next-hop (in PLC, it >seems to be the head-end), and DHCPv6-PD has to be done at that next-hop, >right? >..... > >semi-editorial >-------------- > > If the end customer receives a private IPv4 address and needs to > initiate a tunnel through NAT, techniques like 6to4 may not work > since they rely on Public IPv4 address. In this case, unless the > existing CPE supports protocol-41-forwarding, the end user might have > to use tunnels that can operate through NATs (such as Teredo tunnel > [30]). > > The customer has the option to initiate the tunnel from the device > (GWR) that performs the NAT functionality, similar to the GWR > scenario discussed in section 5.1. This will imply HW replacement or > SW upgrade and a native IPv6 environment behind the GWR. Most GWRs > support protocol-41-forwarding which means that hosts can initiate > the tunnels in which case the GWR is not affected by the IPv6 > service. > >==> you should provide a reference to protocol-41-forwarding. >==> The last sentence of the second paragraph seems badly placed (and >worded). The second paragraph seems to be about GWR v6 support, while the >first paragraph is about host tunneling; the sentence should be moved and >reworded to the first paragraph. > > In inter-domain deployments, Multicast Source Discovery Protocol > (MSDP) [22] is an important element of IPv4 PIM-SM deployments. MSDP > is meant to be a solution for the exchange of source registration > information between RPs in different domains. This solution was > intended to be temporary. This is one of the reasons why it was > decided not to implement MSDP in IPv6 [32]. > > For multicast reachability across domains, Embedded RP could be used. > Despite its shortcomings, MSDP provides additional flexibility in > managing the domains that may not be matched with the protocols > available in IPv6 today. The value of such flexibility is still > under evaluation. > >==> I'd maybe reword the latter paragraph to be more positive, because there >is not going to be MSDP for v6 (and IMHO there is no use portraying MSDP >in a light which might result in the ISPs start asking for it), e.g.: > > For multicast reachability across domains, Embedded RP can be used. > As Embedded RP provides roughtly the equal capabilities but in a slightly > different way, the best management practices for ASM multicast with > embedded RP still remain to be developed. > >.... > > While deploying IPv6 in the above mentioned WLAN architecture, there > are three possible scenarios as discussed below. > > A. Layer 2 Switch Between AP and Edge Router > > B. Access Router Between AP and Edge Router > >==> these options are not exclusive and could possibly be worded a bit >better; the critical thing here seems to be where the customer's traffic is >terminated at L3. In A, it's at Service Provider; In B, it's at Access >Provider. (For example, you can certainly deploy L2 switches in B before >the access router :) > > Just for information/clarification, often the PLC/BPL access networks > use hybrid layer 2 combinations either with PLC/BPL in the medium > voltage, point to point links, wireless links, satellite, etc., but > once more, this seems to be out of the scope of this document, as > those means are transparent, for the purpose of this document, to the > last half mile access network deployed with PLC/BPL. > >==> I'm having difficulty understanding the relevance of this paragraph. >Remove or reword? > >10.2.1 IPv6 Related Infrastructure Changes > > In this scenario the RPT is layer 3 unaware, but not the Head End, > which should be upgraded to support IPv6. Similarly other devices > which have to be upgraded to dual stack: Hosts, RCPE and Edge Router. > >==> just say something like: > > In this scenario only the RPT is layer 3 unaware, but the other devices > have to be upgraded to dual stack: Hosts, RCPE, Head End, and > Edge Router. > >10.2.3 Routing > > If no routers are used on the custmer premises, the HE can simply be > configured with a default route that points to the Edge Router. If a > router is used on the customer premises (RCPE) then the HE will run > an IGP to the ER such as OSPFv3, IS-IS or even RIPng. [...] > >==> whether or not there is RCPE seems independent of whether HE should >run a routing protocol towards ER? Assuming all the customers at HE would >come from the same aggregate route, static routing between HE and ER could >work just fine, even if there were RCPE(s). (Obviously, this doesn't scale >well if all the customer prefixes would need to be statically routed, but >I don't think it's exactly as black & white as the sentence seems to state.) > >10.6 IPv6 Network Management > > There are no differences in terms of network management if compared > with the already described Ethernet case. > >==> are you sure? In ethernet case, we have well-defined MIBs. Do the same >MIBs exist in PLC equipment as well? Do the different PLC setups require >different kind of MIBs? > > [5] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 > Hosts and Routers", RFC 2893, August 2000. > >==> this could probably be replaced with [30], because mech-v2 is already in >RFC-ed queue. > >editorial >--------- > >Note: there have been dozens of typos introduced between -00 and -02; most >of these can be reasonably easily spotted if you run the docs through >'wdiff' (for example, in section 1, "ISP" changed to "IP".) I've not tried >to list these here. > >- in the abstract, "for completion purposes" -> "for completeness" > >- in the abstract, there are a lot of abbreviated terms which either need to >be spelled out or removed. IMHO, we don't need to list all of these in the >abstract; for example, just mention DSL, ethernet and cable as examples >of BB technologies covered. > >- in section 4.2, s/Layer3/Layer 3/ >- in section 4.2, make "RFC4029" a reference. >- in section 5.1, there were a number of abbreviated terms like NAP, SP, >GWR, etc. These should be spelled out. I'd suggest including a very short >"common terminology" subsectin 1.1, where you spell these out in one line >per each. >- in section 5.1 and elsewhere, you've used [[2], [3]] when using multiple >references; please use normal ()'s instead, e.g., ([2], [3]) - in section >5.1 and 5.2, s/Tunnels-Customers/Tunnels - Customers/ >- in section 5.2, s/Public/public/ >- in section 5.2, create an explicit reference for [Tunnel through IPsec] >- in section 9.1, s/IEEE 802.11a offers/IEEE 802.11a/g offer/ > >- in section 10.1, > > Head End (HE): It is the router that connects the PLC/BPL access > network (the power grid), > > ==> remove "It is" (from here and subsequent terms) to be better in line >with the style of the rest of the document? > >- in section 10.1, "Often is a bridge" -> "It is often a bridge" >- in figure 10.1, just replace "HE" with head end (it's short enough) ? > >- in section 10.2.3, s/custmer/customer/ > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --=====================_3867481==_.ALT Content-Type: text/html; charset="us-ascii" Thanks for the comments Pekka.

We'll address the comments and get in touch with you offline if needed.

Please send those couple of pointers you mentioned, to us.

Regards,
Salman

At 10:40 AM 6/17/2005 +0300, Pekka Savola wrote:
On Mon, 6 Jun 2005 fred@cisco.com wrote:
This note starts the WG Last Call for comments on

 "ISP IPv6 Deployment Scenarios in Broadband Access Networks", Salman
 Asadullah, 31-May-05,
 <draft-ietf-v6ops-bb-deployment-scenarios-02.txt>

I did not read the document carefully, because I've already read it many times. However, I think there are still a couple of (relatively minor) issues which require one revision. However, I'd like to keep it at one, and try to get this out for IESG evaluation before Paris IETF, so we could discuss comments (if any) before then.

substantial
-----------

==> There have been at least a couple of recent scientific papers describing some shortcomings in IPv6 BB deployment. I don't think these are available in the web, or are very credible, but I think the authors need to read them and understand why the people felt that there was a shortcoming (and proposed their own fixes). While some of these may be true, most are probably not -- those which are not could probably be more clearly described in this document so we can point folks here. I'll send a couple of pointers off-list.

==> during the 01 -> 02 revision, acknowledgements and contributors sections went missing, please restore these.


  If there is no Customer Router all the hosts on the subscriber site
  belong to the same /64 subnet that is statically configured on the
  Edge Router for that subscriber PVC. The hosts can use stateless
  autoconfiguration or stateful DHCPv6 based configuration to acquire
  an address via the Edge Router.
....
(In gap analysis)
  This approach changes the provisioning methodologies that were used
  for IPv4. Static configuration of the IPv6 addresses for all these
  links on the Edge Routers or Access Routers might not be a scalable
  option. New provisioning mechanisms or features might need to be
  developed in order to deal with this issue.

==> this is related to the point I was making earlier, but I think it
should still be made much more explicit. How about rewording:

  If there is no Customer Router all the hosts on the subscriber site
  belong to the same /64 subnet that may be statically configured on the
  Edge Router for that subscriber PVC. The hosts can use stateless
  autoconfiguration or stateful DHCPv6 based configuration to acquire
  an address via the Edge Router.

  However, as manual configuration for each customer is a provisioning
  challenge, implementations are encouraged to develop mechanism(s) which
  automatically map the VLAN (or some other customer-specific information)
  to an IPv6 subnet prefix, and advertise the customer-specific prefix
  to all the customers with minimal configuration.

(and something similar in the gap analysis.)

...

10.2 Deploying IPv6 in IPv4 PLC/BPL

  The most simplistic and efficient model, considering the nature of
  the PLC/BPL networks, is to see the network as a point-to-point one
  to each customer. Even if several customers share the same physical
  media, the traffic is not visible among them because each one uses
  different channels, which are in addition encrypted by means of 3DES.

  Furthermore, if required, VLANs could also be used, as already
  described for the Ethernet case.

==> PLC sections do not describe at all how IPv4 is done (compare to the
other sections). Does it use PPP (which variant)? Something like
xDSL/Ethernet point-to-point models (which variant)? For consistency and
better understand how PLC works, this should be included.

==> You mention VLANs, but while VLANs are well defined for Ethernet, I'm
not sure what PLC VLANs are? Maybe PLC is emulating Ethernet the same way that 802.11 is, but the document just isn't clear enough about this?

  B. Currently the DHCP-PD functionality cannot be implemented if the
  DHCP-PD server is not the Edge Router. If the DHCP-PD messages are
  relayed, the Edge Router does not have a mechanism to learn the
  assigned prefixes and thus install the proper routes to make that
  prefix reachable. [...]

==> shouldn't you say something like "the first router outside of the
customer premises" instead of Edge Router? (or something a bit more
compact.) As it is, at least in PLC and also in other technologies, what
you call "Edge Router" is not necessarily the CPE's next-hop (in PLC, it
seems to be the head-end), and DHCPv6-PD has to be done at that next-hop,
right?
.....

semi-editorial
--------------

  If the end customer receives a private IPv4 address and needs to
  initiate a tunnel through NAT, techniques like 6to4 may not work
  since they rely on Public IPv4 address. In this case, unless the
  existing CPE supports protocol-41-forwarding, the end user might have
  to use tunnels that can operate through NATs (such as Teredo tunnel
  [30]).

  The customer has the option to initiate the tunnel from the device
  (GWR) that performs the NAT functionality, similar to the GWR
  scenario discussed in section 5.1. This will imply HW replacement or
  SW upgrade and a native IPv6 environment behind the GWR. Most GWRs
  support protocol-41-forwarding which means that hosts can initiate
  the tunnels in which case the GWR is not affected by the IPv6
  service.

==> you should provide a reference to protocol-41-forwarding.
==> The last sentence of the second paragraph seems badly placed (and
worded). The second paragraph seems to be about GWR v6 support, while the
first paragraph is about host tunneling; the sentence should be moved and
reworded to the first paragraph.

  In inter-domain deployments, Multicast Source Discovery Protocol
  (MSDP) [22] is an important element of IPv4 PIM-SM deployments. MSDP
  is meant to be a solution for the exchange of source registration
  information between RPs in different domains. This solution was
  intended to be temporary. This is one of the reasons why it was
  decided not to implement MSDP in IPv6 [32].

  For multicast reachability across domains, Embedded RP could be used.
  Despite its shortcomings, MSDP provides additional flexibility in
  managing the domains that may not be matched with the protocols
  available in IPv6 today. The value of such flexibility is still
  under evaluation.

==> I'd maybe reword the latter paragraph to be more positive, because there
is not going to be MSDP for v6 (and IMHO there is no use portraying MSDP
in a light which might result in the ISPs start asking for it), e.g.:

  For multicast reachability across domains, Embedded RP can be used.
  As Embedded RP provides roughtly the equal capabilities but in a slightly
  different way, the best management practices for ASM multicast with
  embedded RP still remain to be developed.

....

  While deploying IPv6 in the above mentioned WLAN architecture, there
  are three possible scenarios as discussed below.

  A. Layer 2 Switch Between AP and Edge Router

  B. Access Router Between AP and Edge Router

==> these options are not exclusive and could possibly be worded a bit
better; the critical thing here seems to be where the customer's traffic is
terminated at L3. In A, it's at Service Provider; In B, it's at Access
Provider. (For example, you can certainly deploy L2 switches in B before
the access router :)

  Just for information/clarification, often the PLC/BPL access networks
  use hybrid layer 2 combinations either with PLC/BPL in the medium
  voltage, point to point links, wireless links, satellite, etc., but
  once more, this seems to be out of the scope of this document, as
  those means are transparent, for the purpose of this document, to the
  last half mile access network deployed with PLC/BPL.

==> I'm having difficulty understanding the relevance of this paragraph. Remove or reword?

10.2.1 IPv6 Related Infrastructure Changes

  In this scenario the RPT is layer 3 unaware, but not the Head End,
  which should be upgraded to support IPv6. Similarly other devices
  which have to be upgraded to dual stack: Hosts, RCPE and Edge Router.

==> just say something like:

  In this scenario only the RPT is layer 3 unaware, but the other devices
  have to be upgraded to dual stack: Hosts, RCPE, Head End, and
  Edge Router.

10.2.3 Routing

  If no routers are used on the custmer premises, the HE can simply be
  configured with a default route that points to the Edge Router. If a
  router is used on the customer premises (RCPE) then the HE will run
  an IGP to the ER such as OSPFv3, IS-IS or even RIPng. [...]

==> whether or not there is RCPE seems independent of whether HE should run a routing protocol towards ER? Assuming all the customers at HE would come from the same aggregate route, static routing between HE and ER could work just fine, even if there were RCPE(s). (Obviously, this doesn't scale well if all the customer prefixes would need to be statically routed, but I don't think it's exactly as black & white as the sentence seems to state.)

10.6 IPv6 Network Management

  There are no differences in terms of network management if compared
  with the already described Ethernet case.

==> are you sure? In ethernet case, we have well-defined MIBs. Do the same
MIBs exist in PLC equipment as well? Do the different PLC setups require
different kind of MIBs?

  [5]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
        Hosts and Routers", RFC 2893, August 2000.

==> this could probably be replaced with [30], because mech-v2 is already in
RFC-ed queue.

editorial
---------

Note: there have been dozens of typos introduced between -00 and -02; most of these can be reasonably easily spotted if you run the docs through 'wdiff' (for example, in section 1, "ISP" changed to "IP".) I've not tried to list these here.

- in the abstract, "for completion purposes" -> "for completeness"

- in the abstract, there are a lot of abbreviated terms which either need to
be spelled out or removed. IMHO, we don't need to list all of these in the
abstract; for example, just mention DSL, ethernet and cable as examples
of BB technologies covered.

- in section 4.2, s/Layer3/Layer 3/
- in section 4.2, make "RFC4029" a reference.
- in section 5.1, there were a number of abbreviated terms like NAP, SP,
GWR, etc. These should be spelled out. I'd suggest including a very short
"common terminology" subsectin 1.1, where you spell these out in one line
per each.
- in section 5.1 and elsewhere, you've used [[2], [3]] when using multiple
references; please use normal ()'s instead, e.g., ([2], [3]) - in section 5.1 and 5.2, s/Tunnels-Customers/Tunnels - Customers/
- in section 5.2, s/Public/public/
- in section 5.2, create an explicit reference for [Tunnel through IPsec]
- in section 9.1, s/IEEE 802.11a offers/IEEE 802.11a/g offer/

- in section 10.1,

  Head End (HE): It is the router that connects the PLC/BPL access
  network (the power grid),

 ==> remove "It is" (from here and subsequent terms) to be better in line
with the style of the rest of the document?

- in section 10.1, "Often is a bridge" -> "It is often a bridge"
- in figure 10.1, just replace "HE" with head end (it's short enough) ?

- in section 10.2.3, s/custmer/customer/

--
Pekka Savola                "You each name yourselves king, yet the
Netcore Oy                   kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=====================_3867481==_.ALT-- From owner-v6ops@ops.ietf.org Fri Jun 24 20:00:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10671 for ; Fri, 24 Jun 2005 20:00:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dly2G-000LPF-TJ for v6ops-data@psg.com; Fri, 24 Jun 2005 23:56:36 +0000 Received: from [64.104.129.195] (helo=ind-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dly2E-000LOq-Mk for v6ops@ops.ietf.org; Fri, 24 Jun 2005 23:56:34 +0000 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 25 Jun 2005 05:34:42 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,229,1115017200"; d="scan'208"; a="41373074:sNHT21396332" Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5P5Ocru006890 for ; Sat, 25 Jun 2005 05:25:06 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 25 Jun 2005 07:56:00 +0800 Received: from [192.168.1.193] ([10.66.254.104]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 25 Jun 2005 07:56:05 +0800 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <0847eff83e55858b124f9c6a06f95902@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'v6ops@ops.ietf.org '" From: Fred Baker Subject: Fwd: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France Date: Fri, 24 Jun 2005 14:32:25 -0700 X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 24 Jun 2005 23:56:06.0124 (UTC) FILETIME=[49061AC0:01C57918] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Anything anyone wants on the agenda needs a new draft since the March meeting, preferably updated to any discussion that has happened on the mailer, and the authors should send Kurt and I a note requesting agenda time.I have asked for a single two hour slot. Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: June 23, 2005 9:00:01 PM PDT > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF > Meeting in Paris, France > > > There are two (2) Internet-Draft cutoff dates for the 63rd > IETF Meeting in Paris, France: > > July 11th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > July 11th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Tuesday, > July 5th at 9:00 AM ET. > > July 18th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, July 18th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, August 1st at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or > revised Internet-Draft after their respective cutoff deadlines, then > your document will be retained and posted when Internet-Draft > processing resumes. You will no longer be required to resubmit the > document. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 63rd IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_63.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > From owner-v6ops@ops.ietf.org Mon Jun 27 04:56:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26138 for ; Mon, 27 Jun 2005 04:56:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DmpLy-000Bqt-Q2 for v6ops-data@psg.com; Mon, 27 Jun 2005 08:52:30 +0000 Received: from [210.84.234.117] (helo=ubu.nosense.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DmpLw-000Bpu-Fu for v6ops@ops.ietf.org; Mon, 27 Jun 2005 08:52:29 +0000 Received: from ubu.nosense.org (ubu.nosense.org [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 0EBC762AAE for ; Mon, 27 Jun 2005 18:22:18 +0930 (CST) Date: Mon, 27 Jun 2005 18:22:17 +0930 From: Mark Smith To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Message-Id: <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.0beta1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On Sat, 18 Jun 2005 01:18:42 +0930 Mark Smith wrote: > Hi, > > "6.2 Subnet topology masking > > There really is no functional gap here as a centrally assigned > pool of addresses in combination with host routes in the IGP is an > effective way to mask topology. " > > I'm wondering if the above is actually the case. > > I think host routes are easy enough to understand from the point of view > of propagating /128s around within an IGP. > > What I'm curious about is how the end-nodes are configured and how they > operate, in particular when they are attached to a broadcast > multi-access link e.g., an ethernet. Has this operation been discussed or > described in an ID or RFC that I'm not aware of ? > It looks like a /128 prefix length is not permitted on an interface, according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think means most of the issues I was concerned about described disappear. I'm still not sure exactly how host routing would work from the end-nodes point of view, so I'll continue to do some reading. It seems to me that hiding the network or subnet topology by not grouping IPv6 addresses according to their common data links means that the subnet bit portion of the address loses its significance when determining whether a destination address is off or onlink, during Neighbour Discovery. Thanks, Mark. From 2huey@about.com Tue Jun 28 05:51:54 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18110 for ; Tue, 28 Jun 2005 05:51:54 -0400 (EDT) Received: from [221.201.16.43] (helo=221.201.16.43) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DnDAM-0001OC-60 for v6ops-archive@ietf.org; Tue, 28 Jun 2005 06:18:07 -0400 Message-ID: From: "Vanessa J. Smith" <2huey@about.com> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgUGhvdG9zaG9wIDguMCAtIHdob2xlc2FsZSBwcmljZQ==?= Date: Tue, 28 Jun 2005 09:40:16 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_E4729A30.51F15C3D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.4 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is a multi-part message in MIME format. ------=_NextPart_000_0000_E4729A30.51F15C3D Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_A3D2C4A4.7C8F3DCB" ------=_NextPart_001_0001_A3D2C4A4.7C8F3DCB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the popular software you ever imagined for prices substantially lower than in stores! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Please visit us at: http://www.softdisks-ltd.com Best, Vanessa Smith _____________________________________________________ To be taken off future campaigns, go here: http://www.softdisks-ltd.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_A3D2C4A4.7C8F3DCB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get access to all the popular software you ever imagined for prices substantially lower than in stores!
We sell software 2-6 times cheaper than retail price.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... Please visit us at:

http://www.softdisks-ltd.com

Best,
Vanessa Smith


_____________________________________________________
To be taken off future campaigns, go here: http://www.softdisks-ltd.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_A3D2C4A4.7C8F3DCB-- ------=_NextPart_000_0000_E4729A30.51F15C3D-- From owner-v6ops@ops.ietf.org Wed Jun 29 04:12:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnXgU-0005la-Sx for v6ops-archive@megatron.ietf.org; Wed, 29 Jun 2005 04:12:39 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21130 for ; Wed, 29 Jun 2005 04:12:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DnXbf-0008Xu-Cq for v6ops-data@psg.com; Wed, 29 Jun 2005 08:07:39 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DnXbd-0008X1-NX for v6ops@ops.ietf.org; Wed, 29 Jun 2005 08:07:37 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 29 Jun 2005 01:07:35 -0700 X-IronPort-AV: i="3.93,241,1115017200"; d="sig'?scan'208"; a="195176825:sNHT36014276" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5T87WvM002326; Wed, 29 Jun 2005 01:07:32 -0700 (PDT) Received: from [10.113.37.201] (sjc-vpn7-39.cisco.com [10.21.144.39]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j5T8753U024410; Wed, 29 Jun 2005 01:07:06 -0700 In-Reply-To: <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <20050618011842.656c62f1.ipng@69706e6720323030352d30312d31340a.nosense.org> <20050627182217.773a77b1.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--8669435" Message-Id: Content-Transfer-Encoding: 7bit Cc: v6ops@ops.ietf.org From: Fred Baker Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt Date: Wed, 29 Jun 2005 09:07:31 +0100 To: Mark Smith X-Pgp-Agent: GPGMail 1.0.2 X-Mailer: Apple Mail (2.622) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1120032427.309208"; x:"432200"; a:"rsa-sha1"; b:"nofws:1372"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"WHpzpN8SuZHcGvMQRQhmGwvX5Pk74jUtsJV1F1lpENwaCmj2jk/aX6FPpNpAeCnCrgsoM9RX" "JaqQ7IGouVfQ8hWUNdrxHPWCexc2PxhqKR0rP0bgqzA2qB3FmsZXsECfcO6HfzT506pd3sPGHxp" "JEWbD7OGjLgTXfcZmyCrxz5E="; c:"From: Fred Baker "; c:"Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt"; c:"Date: Wed, 29 Jun 2005 09:07:31 +0100" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-4--8669435 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jun 27, 2005, at 9:52 AM, Mark Smith wrote: > It looks like a /128 prefix length is not permitted on an interface, > according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think means > most of the issues I was concerned about described disappear. For the record, a /32 is now permitted on an interface in IPv4. This permits allocation of such to a loopback interface, for example. It may be worthwhile to find the use cases for that and ask whether they apply to IPv6. > I'm still not sure exactly how host routing would work from the > end-nodes point of view, so I'll continue to do some reading. It seems > to me that hiding the network or subnet topology by not grouping IPv6 > addresses according to their common data links means that the subnet > bit portion of the address loses its significance when determining > whether a destination address is off or onlink, during Neighbour > Discovery. More generally, when addresses cannot be summarized, summarization functions break down. Your friendly neighborhood ISP will have issues with this. --Apple-Mail-4--8669435 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCwlbDbjEdbHIsm0MRApzyAJkB3UQdl9ucI5xN6JQ5FuQ2C57TEQCfT2HS mxHQ2yK7vcN4NLcxjR1wRqk= =1SuQ -----END PGP SIGNATURE----- --Apple-Mail-4--8669435--