From owner-v6ops@ops.ietf.org Wed Sep 1 11:06:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24406 for ; Wed, 1 Sep 2004 11:06:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2U1o-00034F-PA for v6ops-data@psg.com; Wed, 01 Sep 2004 12:15:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2U1d-00033J-TG for v6ops@ops.ietf.org; Wed, 01 Sep 2004 12:15:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i81CFew22429 for ; Wed, 1 Sep 2004 15:15:40 +0300 Date: Wed, 1 Sep 2004 15:15:40 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-mech-v2-06.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 31 Aug 2004, Pekka Savola wrote: > However, to fix the problem pointed out by 1) in a slightly better > way, I'd suggest wording like (changes in the first sentence only): > > The encapsulating IPv4 header is discarded, *and the resulting packet > is checked for validity when submitted to the IPv6 layer*. When > reconstructing the IPv6 packet the length MUST be determined from the > IPv6 payload length since the IPv4 packet might be padded (thus have a > length which is larger than the IPv6 packet plus the IPv4 header being > removed). > > If you have comments/objections to this, please state them > ****off-list**** within a day or so. (co-chair hat on) Due to receiving only positive feedback, the -06 version incorporating the WG consensus has been submitted for publication. It can also be found at, along with a number of htmlwdiffs: http://www.netcore.fi/pekkas/ietf/temp/ Please bring up any [serious] issues you might have with -06 version by Monday, September 6th at the latest. I'll try to get this on the next IESG agenda (DL for items is on 9th). Thanks! (hat off) -- 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 Wed Sep 1 11:06:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24546 for ; Wed, 1 Sep 2004 11:06:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2SMs-000Hy0-Sv for v6ops-data@psg.com; Wed, 01 Sep 2004 10:29:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2SMh-000Hwz-Mk for v6ops@ops.ietf.org; Wed, 01 Sep 2004 10:29:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i81ATHv19929 for ; Wed, 1 Sep 2004 13:29:17 +0300 Date: Wed, 1 Sep 2004 13:29:17 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: zeroconf requirements document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (co-chair hat on) The document editor just said that a revised version, addressing the input received so far, could be available for tomorrow. So, please hold off the review until the new revision has been made available (-01 version). Let's shift the review DL by one day, to 7th September. Thanks to the surprisingly active document editor and authors! :-) (hat off) On Wed, 1 Sep 2004, Pekka Savola wrote: > (co-chair hat on) > > If you recall from the IETF60 meeting, we set out a couple of > milestonoes and deadlines to make progress well before the next > meeting -- and now the planning and scheduling for IETF61 has already > started... > > We need to get more input especially on: > > http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-00.txt > > Please read it and send feedback on the list. Please do this as soon > as possible but on 6th September at the latest. > > In particular, opinions on whether the document should include the > applicability in the ISP networks (e.g., when the access network > cannot be upgraded [which seems to have similar requirements as 3GPP]) > would be highly appreciated. > > Thanks! > > (hat off) > > -- 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 Wed Sep 1 11:06:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24550 for ; Wed, 1 Sep 2004 11:06:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2RPY-000Bbn-B2 for v6ops-data@psg.com; Wed, 01 Sep 2004 09:28:12 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2RPM-000BaS-UL for v6ops@ops.ietf.org; Wed, 01 Sep 2004 09:28:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i819Rxn18297 for ; Wed, 1 Sep 2004 12:27:59 +0300 Date: Wed, 1 Sep 2004 12:27:59 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: REVIEW NEEDED: zeroconf requirements document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) If you recall from the IETF60 meeting, we set out a couple of milestonoes and deadlines to make progress well before the next meeting -- and now the planning and scheduling for IETF61 has already started... We need to get more input especially on: http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-00.txt Please read it and send feedback on the list. Please do this as soon as possible but on 6th September at the latest. In particular, opinions on whether the document should include the applicability in the ISP networks (e.g., when the access network cannot be upgraded [which seems to have similar requirements as 3GPP]) would be highly appreciated. Thanks! (hat off) -- 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 Wed Sep 1 12:46:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07638 for ; Wed, 1 Sep 2004 12:46:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2YD5-0009DK-Mo for v6ops-data@psg.com; Wed, 01 Sep 2004 16:43:47 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2YCr-0009CJ-Jy for v6ops@ops.ietf.org; Wed, 01 Sep 2004 16:43:34 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 01 Sep 2004 12:43:33 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i81GhTZQ027710; Wed, 1 Sep 2004 12:43:29 -0400 (EDT) Received: from CPOPOVIC-W2K1.cisco.com (dhcp-64-102-202-67.cisco.com [64.102.202.67]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BBR39868; Wed, 1 Sep 2004 09:43:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20040831213539.018e7e80@fruitpie.cisco.com> X-Sender: cpopovic@fruitpie.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Sep 2004 12:38:56 -0400 To: Pekka Savola From: Ciprian Popoviciu Subject: Re: Draft on ISP broad-band deployment scenarios Cc: v6ops@ops.ietf.org, Adeel Ahmed , Salman Asadullah , Patrick Grossetete In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, First we would like to thank you for the detailed comments and suggestions made on this draft. They are very appreciated! Please find in line our response and questions. We are looking forward to your response. Regards, Chip At 01:17 PM 8/24/2004 +0300, Pekka Savola wrote: >Hi, > >Sorry for delay in sending in a few personal comments... > >On Thu, 19 Aug 2004, Pekka Savola wrote: > > Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a > > lot of work in a very short time and produced a really extensive > > scenarios document discussing the IPv6 deployment scenarios for > > broadband (DSL, cable, etc.). > >A couple of general observations: > > 0) is the document aiming to only describe the scenarios, or is the >goal to also provide analysis where potential gaps have been >identified, and where e.g., a tunneling mechanism would be needed? If >the latter, it probably needs to be expanded a bit. @@@ Pekka, to put this document in perspective, here are some elements of our original intent: - focus on production type deployments. We did not intend to discuss tunneling unless it is the only alternative currently available due to limitations of a given access technology (cable). - present the possible deployment scenarios and identify the major elements for each one in terms of enabling IPv6 services. - highlight changes that have to be made in the deployment process and some issues that the SP has to keep in mind while planning such a deployment. As you can see, the document is rather large as it is so we did not consider going into more detail then we already did. We did want however to underline topics that should be kept in mind during deployment, even items that should be further investigated. We believe that this approach is what you mentioned above but maybe we need to highlight more some aspects of the document. Could you clarify your comment above so that we make sure we properly understand the changes you suggest? We would like to make this work as useful as possible. @@@ > 1) the doc seems to be lacking large-scale v6 enablement >considerations, w/o customer interaction and manual config. That is, >at least in section 5, I got the impression that for the customer to >enable v6 over a tunnel, the customer and the ISP would have to do >some manual configuration. This seems unscalable and unfeasible. >Shouldn't we try to have mechanisms where the nodes automatically >detect if IPv6 is available through a tunnel, and activate it if so? @@@ This is a good point that we should elaborate on. It is also true that while in some cases simple provisioning is available (use of autoconfig or DHCP-PD) in others there might not be a solution available today. In such cases, based on your comment above, it looks like you would like to see us clearly identify such limitations and possibly open the door for further work. Is this correct? The tunnel case might be an unfortunate example as it might be a temporary solution until an updated DOCSIS allows a more practical approach. @@@ > 2) the document seems to make some assumptions e.g., when it specifies to >use 6to4 e.g., for cable. Are all of the networks using public v4 >addresses? What if the customer has deployed a NAT box so that the public >address is consumed by that box? Further, I'm not sure whether the >situation where the customer has deployed some equipment has been considered >throughout the document. @@@ Again, it is a case very specific to the current state of Cable access. Nevertheless we could probably offer more detail for this case. For example, one solution would be to have the box that is doing the NAT for the user also terminate the tunnel. This is another point that we need to clarify however, the Gateway Router (GWR) can be SP owned but also it can be customer owned and in that case it would reflect a customer deployed equipment like a box that does NAT for v4. @@@ > 3) there's duplicated text in very many of the sections which applies >to about all the scenarios, for example: > > Depending on the design of the edge portion of the ISP network, some > Edge Routers might have to run iBGP for IPv6. In this case it is > expected that two peer sessions are established between the Edge > Router and a pair of redundant Route Reflectors. > >.. instead of duplication, would there be a good logical place to put >all the "generic considerations" wrt. access networks (e.g., about >prefix summarization, etc.) into a dedicated section? -- And just >describe the access-network -specific issues under the access >network.. that might remove duplicate text and make the document more >concise. > >This might force the reader to think about the generic issue and how they >map to the specific access network scenario a bit more, but it would >probably improve the readability and correctness. > >The tradeoff of course is that each access network description would no >longer be readable on its own without reading the rest, but that should >probably be acceptable ... as it is, there seems to be significant overlap >with the sections, especially with DSL, Ethernet, and WLAN, but a bit >otherwise as well. > >If that was done, it might be possible to push down from 60 pages to >20-30 pages, and even increase the amount of unique content in the >process. @@@ Before writing the document we actually discussed this topic amongst ourselves. Our thought is that some items might seem similar between sections but they might not be in all their details. Moreover, we did want to provide each Access Technology section a certain completeness and independence in order to make the sections more readable, without having to send the reader very far through referencing. Even if we were to compress the repeated subsections we doubt that the document will shrink to only 30 pages. We received pro and con arguments on this topic so for now we would like to keep it in this format as it might even be easier to further flesh out some sections based on the feedback received. As the document evolves we can revisit the formatting if it proves advantageous. @@@ > 4) the doc could probably include a summary section just before >Acknowledgements (btw, Security Considerations section needs to be >added), which could list action items for the IETF standardization (if >any gaps were identified), or some other summary of issues which still >need to be taken care of -- or is it just a matter of implementation >and deployment? :-) @@@ Agreed, good idea, we will work on this item. @@@ >substantial >----------- > >5.2.1 Deploying IPv6 in a Bridged CMTS Network > > > > > In IPv4 the CM and CMTS act as Layer-2 bridges and forward all data > traffic to/from the hosts and the ER. The hosts use the ER as their > Layer-3 next hop. If there is a GWR behind the CM it can acts as a > next hop for all hosts and forward data traffic to/from the ER. > >==> doesn't this seem in conflict with 5.2.1.3 which says that the equipment >is doing a significant amount of snooping? How much of this is required to >support v6 bridging? The doc should be very clear where this support is >needed... > >[[ I wrote the below before I read 5.2.1.3: > >Do the bridged-mode cable modem systems use something like the >bridged-mode DSL to make it look like that the customers share the LAN and >are bridged, but actually aren't? (see draft-melsen-mac-forced-fwd-02.txt) > >If yes, that snooping functionality needs to be upgraded to v6. If not, >does that mean that all the ARP/ND traffic is flooded to everyone, and >ARP/ND spoofing/hijacking is trivial? >]] @@@ We will add some clarification in where the snooping is applied. Your comment is valid, the bridged-mode cable modem systems act similar to the bridged-mode DSL. @@@ >semi-editorial >-------------- > >2. IPv6 Based BB Services > > > At this point IPv6 based services are seen as a differentiator > that enables SPs to take advantage of the large IPv6 address > space and allows them to better position themselves against the > competition. Another reason of IPv6 being very popular in some > countries is the government driven financial incentives and > favorable legislation to the ISPs who are deploying IPv6. > >==> one thing possibly worth mentioning here is that some ISPs might see >IPv6 as a way to drive down customer support costs (I've heard this from one >SP at least), because NATs which break apps and in general behave in strange >ways would disappear. @@@ Agreed, we will add this point. @@@ >==> maybe add after this paragraph something along the lines: > > Below, we illustrate a few deployed cases for IPv6-based BB services. > It is not an exhaustive list. @@@ It would be worth pointing out that in this document we went not only for describing some scenarios already deployed but also some that could be deployed. We wanted to present as complete of a list as possible. @@@ >... > >It should be noticed that > where a home user generally gets a single IPv4 address (dynamic > or static), the IPv6 service provides a full subnet (/64). @@@ We will underline this point even thought it might be apparent from the addressing sections. @@@ >==> actually, the current recommendation (RFC 3177) is even larger: a /48 >per home :-). This should probably be mentioned.. @@@ True. We sort of touched on that with our DHCP-PD recommendations. There are also SPs that might assign prefixes between /48 and /64 with the intent of charging for address space. @@@ > 2. IPv4 Cable (HFC) Network, GWR at customer site > > > > > In this case the cable network, including the CM and CMTS remain > IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This > scenario is also easy to deploy since the cable operator just needs > to add GWR at the customer's site. > >==> is this necessarily this simple? What is the cable operator already has >deployed v4-only GWR for other purposes? Does it need to be upgraded to >dual-stack? Or what if the user has added a box of its own, e.g., a >firewall/NAT/wireless router? I guess it again needs to be upgraded. @@@ These are deployment issues that we could elaborate a bit more on. The provider usually is not responsible for the additional equipment added by the customer and under the constraints of a service deployment that is limited by the current state of DOCSIS it is likely that the provider will have to provide a new device to the subscriber. We will add a note on this topic. @@@ > 4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS support > IPv6 > > > > > In this scenario there is a standalone GWR connected to the CM. > Since the IPv6 functionality exists on the GWR the CM does not need > to be dual-stack. The CMTS is upgraded to dual-stack and it can > incorporate the ER functionality. This scenario may also require HW > and SW changes on the GWR and CMTS. > >==> I don't really understand the cable architecture very well, so this may >be an obvious point .. but I don't see how just upgrading GWR and CMTS could >be enough, if the CM doesn't support v6? Does that require some sort of >tunneling, or..? But in that case, v6 support shouldn't be needed in CMTS >in the first place? @@@ The CM will still be a Layer 2 bridge and will bridge IPv4 and IPv6 traffic. Therefore the CM does NOT need to support IPv6. Changes to the DOCSIS specification will need to be made in order for the CM to support IPv6 unicast and multicast traffic. @@@ >5.2.2.2.4 Routing > > > For 6to4 tunneling,a static 2002::/16 route and a default IPv6 route > can be manually configured on the GWR with the IPv6 address of the ER > as the next hop. A similar IPv6 route will need to be configured on > the ER pointing back to the GWR at customer site. > >==> does that require manual configuration at ER for each customer? >Hopefully not! (AFAICS, there's nothing needed for 6to4, but manual >tunneling would need it.) @@@ We will discuss provisioning in more detail and hopefully this question will be answered in that context. It is worthwhile to note that we don't advocate the use of a specific tunneling mechanism for this temporary solution for Cable Networks. We will more clearly identify items to be considered when making the selection for the tunnel but the selection will be left to the person planning the deployment. @@@ > If using maunual tunneling, the GWR and ER can use static routing or > they can also configure RIP-ng. The RIP-ng updates can be transported > over a manual tunnel, which does not work when using 6to4 tunneling. > >==> is there a particular usage case for RIP-ng over cable modem to the GWR? >I can't see any valid scenario for doing so.... @@@ This is a valid point. We need to provide more context to the statement, but it is worthwhile to note that it is a current practice in IPV4 networks where business customer do run RIPv2 between the CM/GWR and the CMTS. Those customer routes are redistributed in the ISP's IGP. @@@ > The CMTS/ER should protect the ISP network and the other subscribers > against attacks by one of its own customers. For this reason uRPF and > ACLs should be used on all interfaces facing subscribers. Filtering > should be implemented with regard for the operational requirements of > IPv6 (ICMPv6 types). > >==> I don't understand what you mean by the last sentence? @@@ We probably used too few words. We wanted to say that while configuring IPv6 ACLs, one has to make sure that the ACLs do not stop IPv6 specific controll plane traffic (like ND, DHCP-PD etc). @@@ >5.2.2.5.4 Routing > > > > > The CM/GWR can use a static defaul route pointing to the CMTS/ER or > it can run a routing procotol such as RIP-ng or OSPFv3 between itself > and the CMTS. Customer routes from behind the CM/GWR can be carried > to the CMTS using routing updates. > >==> are there really any customers or ISPs which would be allowing running a >dynamic routing protocol across the cable modem fabric? I'd be surprised to >see this... @@@ Same comment as above. @@@ > In IPv6, with [RFC3306] there is a better mechanism available for ASM > IPv6 address allocation than in IPv4. This reduces the problems of > using ASM in IPv6 to some degree. On the other hand, the protocol MSDP > standard with PIM-SM is not currently defined for IPv6. In general, > SSM for IPv6 is also considered to be the protocol to promote for the > majority of future interdomain IP multicast applications and it is > less complex solution to operate. > >==> you might want to check out and refer to >draft-ietf-mboned-ipv6-multicast-issues-00.txt which discusses exactly this >issue, and solutions if you'd still need ASM. @@@ Yes, we are aware of this work and we will reference it. We didn't really want to get into a model other then SSM despite the fact that there are feasible ways for ASM. The idea was that SPs will be more inclined to go for an SSM model at first (maybe even on a longer run) because of the business model of content delivery (video/audio). Probably we should however have a discussion on the topic. Do you see the ASM discussion important beyond referencing the draft you mentioned? @@@ >6.2.1 POINT-TO-POINT MODEL > > >==> this model has the built-in assumption that ATM is used as >point-to-point. Is this strictly necessary, or could you just use any other >media as well? @@@ Could you please clarify this comment? @@@ > If a Customer Router is present: > >[...] > - it dynamically acquires through autoconfiguration the address for the > link between itself and the Edge Router. This step is followed by a > DHCP-PD [RFC 3633] request for a prefix shorter then /64 that in turn is > divided in /64s and assigned to its interfaces connecting the hosts on > the customer site. > >==> s/present/present, either:/ > >==> the router doesn't autoconfigure the address unless it has been >configured to act as a host on its upstream interface... which would >probably be bad practice.. so either the upstream link has no global >addresses (which would be OK), or it could just use a subnet from the >DHCP-PD prefix. @@@ Why would you see it as a bad practice having the router acquire via stateless autoconfig an address for the uplink to the provider? We should probably discuss all options for completeness purposes. @@@ > MLD authentication, authorization and accounting is usually > configured on the edge router in order to enable the ISP to do > controll the subbscriber access of the service and do billing for > the content provided. > >==> the non-standardized methods for adding AAA to IGMP/MLD have been >proposed, but they're generally considered very broken models, and I'm not >sure how much text we should have about them, at least without disclaimers. >The right thing to do would probably be to encrypt the data, and provide the >decryption key only to those who pay (or whatever for the stream. @@@ We believe that such a feature is important to all SPs that deploy mcast services for video and audio streaming. Maybe this is not critical at the start of the service but would be when the service offering solidifies. Such a feature offers more granularity in controlling and charging a customer then the key proposal. With the key proposal the user would have access to possibly a predefined package of channels while with proper MLD AAA the user can select any channel, any time and be charged only for that use. @@@ >9. Acknowledgements > >==> would it be appropriate to refer to the earlier work by C. Mickles et >al., here? Depends on how much it has influenced your work, I guess.. @@@ We referenced this work repeatedly in the draft and that in itself would suggest that it would be good to recognize the authors in the acknowledgments section. Good point. @@@ @@@ We will include all editorial comments you made below. @@@ >editorial >--------- > >==> some lines go over the maximum of 72 chars/line > >==> you should spell out the acronyms when they're first used like "Service >Provider (SP)". > >==> there are a couple of non-ascii characters, like the apostrophe in >"IPv6's" in the second paragraph of section 1, in 2nd para of sect 2, etc. > > that are currently deployed, and discussed in this draft. In this > >==> s/draft/memo/ (also later in section 3, and later on) >[[ "memo" is a more generic term which also applies when/if a draft becomes >RFC ]] > > For instance in Japan, Cable TV and dish services are not very > >==> s/Cable/where Cable/ > > Provider's network namely Cable/HFC, BB Ethernet, xDSL and WLAN. > >==> s/network/network,/ > > This drafts briefly discusses the other elements of a provider's > >==> s/drafts/memo/ > > Following important pieces such as: > >==> reword to something like: "We'll consider at least the following >important steps:" ? > > IPv6 deployment is signficant. > > >==> s/sign/signi/ > > A. IPv6 Tunneling: As a temporrary solution, the Access Provider can > >==> s/rrary/rary/ > > least impact on the Access Provider network however it is not suitable > >==> s/however/, however,/ > > C. MPLS 6PE Deployment: If the Access Provider is running MPLS in its > IPv4 core it could use 6PE to forward IPv6 traffic over its MPLS core. > >==> add reference to the 6PE draft? > > In an IPv4 routed CMTS network the CM still acts as a Layer-2 > device and bridges all data traffic between its Ethernet interface > and cable interface > >==> the line ended abruptly, is something missing or was this just an >unnecessary line break? > > When deploying IPv6 in a routed CMTS network, the CM will still acts > >==> remove "will" or s/acts/act/ > > In this scenario the CMTS isupgraded to dual-stack to support IPv4 > >==> s/is/is / > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _() > 6to4 tunnel > >==> s/6to4/IPv6-over-IPv4/ (to be more generic..?) > > messges on its downstream interface which will be used by the hosts to > >==> s/mess/messa/ > > In this case the cable operator can offer IPv6 services to it's > >==> s/it's/its/ (similar elsewhere) > > The CM/GWR can use a static defaul route pointing to the CMTS/ER or > >==> s/defaul/default/ > > enhance security. The Privacy extenssions for autoconfiguration should > >==> s/extens/exten/ > > valid customer controll traffic such as: Router and Neighbor > >==> s/controll/control/ > > Router for that subsrciber's PVC. The hosts can use stateless or > >==>s/rc/cr/ > > DHCP-PD should be planned in a maner that allows as much summarization > >==> s/maner/manner/ > > should be planned in a maner that allows maximu summarization BRAS. > > >==> same here, + s/maximu/maximum/ > >[[there were a large number of other typos I didn't correct, as a lot >of them were duplicated across the document]] > >-- >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 Wed Sep 1 15:35:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24839 for ; Wed, 1 Sep 2004 15:35:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2aqk-0003bs-Qy for v6ops-data@psg.com; Wed, 01 Sep 2004 19:32:54 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2apX-0003Un-LW for v6ops@ops.ietf.org; Wed, 01 Sep 2004 19:31:39 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Sep 2004 15:31:39 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i81JVYUu029034; Wed, 1 Sep 2004 15:31:34 -0400 (EDT) Received: from CPOPOVIC-W2K1.cisco.com (dhcp-64-102-202-67.cisco.com [64.102.202.67]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BBR57978; Wed, 1 Sep 2004 12:31:33 -0700 (PDT) Message-Id: <4.3.2.7.2.20040901124020.018d0200@fruitpie.cisco.com> X-Sender: cpopovic@fruitpie.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Sep 2004 15:27:02 -0400 To: Brian E Carpenter From: Ciprian Popoviciu Subject: Re: I-D ACTION:draft-asadullah-v6ops-bb-deployment-scenarios-00.txt Cc: IPv6 Operations , patrick Grossetete In-Reply-To: <412DFD59.70709@zurich.ibm.com> References: <200408191927.PAA27427@ietf.org> <200408191927.PAA27427@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Brian, Thank you for your comments and suggestions. Please find in line our answers, clarifications and questions. We are looking forward to your response and suggestions. Regards, Chip At 05:10 PM 8/26/2004 +0200, Brian E Carpenter wrote: >Just a few quick comments on this very long document, which I >think fills a need (though whether it should be an RFC, or >expanded into a book, I'm not quite sure). > >1) I think I disagree with one comment Pekka made, about the >same material being repeated in several sections. I think each of the >major sections should be complete in itself, to avoid complex cross- >references. > >2) Here's a comment that I think applies to all four scenarios described. >The case of subscribers that get more than a /64, actually a /48 if >RFC 3177 is followed, is not described, unless I missed it. This may only >apply to a minority of subscribers initially, but it must certainly >be covered. @@@ We touched on this subject partially when mentioning the use of DHCP-PD used to assign /48 to customer premises routers. We are planning to add more information on this topic so this comment will be integrated in the next iteration. @@@ >3) Just an observation: the document implies in all scenarios that GWR >vendors will update their products to be fully dual stacked. I can only >agree that is highly desirable, but you are asking for quite a lot. @@@ This is true but our intent was to look forward to large scale deployments where IPv6 is more then a service. We argued that the user can simply get connectivity through dual stack PCs that talk to the SP edge access equipment however, on the long run the users and providers will drive the CPE manufacturers to get the GWR ready for dual stack use. @@@ >4) Section 5.2.2.1.3 > >>5.2.2.1.3 Data Forwarding >> >> All IPv6 traffic will be sent to/from the ER and the host device. >> In order to transport IPv6 packets over the cable operator's >> IPv4 network, the host and the ER will need to use tunneling >> mechanisms such as 6to4 tunneling [RFC 3056]. >> >> The host will use its global IPv4 address to source the tunnel to >> the ER. > >So, as Pekka also pointed out I think, you are assuming global IPv4 >addresses at this level. What about countries that are already running >multiple levels of NAT in order to reach local ISPs? 6to4 is broken in >that case. Also, you don't explain how the 6to4 relay is discovered - >do you assume the anycast trick is used (RFC 3068)? And incidentally it >means that all such hosts will have 6to4 prefixes, so baroque routing >is likely. 6to4 was designed to *bypass* local ISPs without IPv6 support, >not to *help* them. @@@ Our intent was to describe non-tunnel based deployments but rather deployments similar to the IPv4 ones. The cable access case study is special because of the current state of DOCSIS. This is the reason why tunnels were used here. That being said, based on the comments we received, it is clear that we need to expand a bit more on the topic and provide some clarifications. We will make some additions and keep in mind the point raised by this comment. @@@ >5) Section 5.2.2.2 > >> The cable operator can provide IPv6 services to its customers, >> in this scenario, by adding a GWR behind the CM. Since the GWR >> will facilitate all IPv6 traffic to/from the host and the ER, the >> cable network including the CM and CMTS do not need to support IPv6 >> and can remain IPv4 devices. > >But this also has to work when the subscriber goes to the local >electronics store and buys $99 Wireless Access Gateway, without the >cable operator lifting a finger. Incidentally, in this case, if >you use 6to4, the GWR will have to be a full RFC 3056 6to4 router, >but the hosts behind the GWR don't need to know anything about 6to4. @@@ True, this falls a bit in the topic of who owns the GWR. Yes, having the GWR do the 6to4 tunneling is one of the ways to deal with having a single globally routable IPv4 address that might be used with NAT for existent v4 connectivity. We will elaborate on the topic since it was brought up in other feedback we received. @@@ >6) Section 7.5 > >> The NAP can stop IPv6 traffic from customer that did not subscribe >> to the service by using layer two filters based on the IPv6 >> Ethertype (0X86DD). > >I think this is irrelevant - it isn't related to a security threat. It's >also getting into business model territory, which we try to >avoid in the IETF. @@@ In a bridged network, wouldn't this be useful as a means for an access provider to keep its network IPv6 free if it so decides? @@@ >7) Section 10, References > >You mention RFC 3056 in the text, but it isn't listed. Also, as noted above, >do you also need a reference to RFC 3068? @@@ Noted, we will make the necessary corrections. @@@ > Brian > >Internet-Drafts@ietf.org wrote: >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> Title : ISP IPv6 Deployment Scenarios in Broadband >> Access Networks >> Author(s) : S. Asadullah, et al. >> Filename : >> draft-asadullah-v6ops-bb-deployment-scenarios-00.txt >> Pages : 0 >> Date : 2004-8-18 >> >>This document provides detailed description of IPv6 deployment >>and integration methods and scenarios in today's Service Provider >>(SP) Broadband (BB) networks in coexistance with deployed IPv4 services. >> Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB >> technologies that are currently deployed, and discussed in this >> draft. In this document we will discuss main components of IPv6 BB >> networks and their differences from IPv4 BB networks and how IPv6 is >> deployed and integrated in each of these BB technologies. >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-00.txt From owner-v6ops@ops.ietf.org Wed Sep 1 16:12:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28053 for ; Wed, 1 Sep 2004 16:12:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2bRl-0008f7-Q5 for v6ops-data@psg.com; Wed, 01 Sep 2004 20:11:09 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2bQx-0008bL-0f for v6ops@ops.ietf.org; Wed, 01 Sep 2004 20:10:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27936; Wed, 1 Sep 2004 16:10:15 -0400 (EDT) Message-Id: <200409012010.QAA27936@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-06.txt Date: Wed, 01 Sep 2004 16:10:15 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 : Basic Transition Mechanisms for IPv6 Hosts and Routers Author(s) : E. Nordmark, R. Gilligan Filename : draft-ietf-v6ops-mech-v2-06.txt Pages : 33 Date : 2004-9-1 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, 'dual stack' and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-06.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-mech-v2-06.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-mech-v2-06.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: <2004-9-1163659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-mech-v2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-mech-v2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-1163659.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Sep 2 08:59:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00149 for ; Thu, 2 Sep 2004 08:59:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2r8o-0000sh-Si for v6ops-data@psg.com; Thu, 02 Sep 2004 12:56:38 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2r8T-0000of-KK for v6ops@ops.ietf.org; Thu, 02 Sep 2004 12:56:18 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i82CuGWR024231 for ; Thu, 2 Sep 2004 14:56:16 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 14:56:16 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id R84FATSW; Thu, 2 Sep 2004 14:56:16 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Sep 2004 14:56:16 +0200 Message-ID: X-Sybari-Trust: e2cdff9f 477d8de1 f882b225 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: RE: REVIEW NEEDED: zeroconf requirements document Date: Thu, 2 Sep 2004 14:56:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Sep 2004 12:56:16.0548 (UTC) FILETIME=[3BEFF640:01C490EC] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Dear All, The promised revised version, draft-nielsen-v6ops-zeroconf-goals-01.txt, can be found on the following link: http://www.v6ops.euro6ix.net/zerotunnel.php# On behalf of the authors I would like to echo Pekka's request for a review of this work. Feedback are requested on the general scope of the documents as well as on the particular set of individual goals put forward. Please scrutinize. BR, Karen The drafts has been submitted to the IDs, but it will probably take a while for it to appear. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Pekka Savola > Sent: Wednesday, September 01, 2004 12:29 PM > To: v6ops@ops.ietf.org > Subject: Re: REVIEW NEEDED: zeroconf requirements document > > > (co-chair hat on) > > The document editor just said that a revised version, addressing the > input received so far, could be available for tomorrow. > > So, please hold off the review until the new revision has been made > available (-01 version). Let's shift the review DL by one day, to 7th > September. > > Thanks to the surprisingly active document editor and authors! :-) > > (hat off) > > On Wed, 1 Sep 2004, Pekka Savola wrote: > > (co-chair hat on) > > > > If you recall from the IETF60 meeting, we set out a couple of > > milestonoes and deadlines to make progress well before the next > > meeting -- and now the planning and scheduling for IETF61 > has already > > started... > > > > We need to get more input especially on: > > > > http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-00.txt > > Please read it and send feedback on the list. Please do this as soon > as possible but on 6th September at the latest. > > In particular, opinions on whether the document should include the > applicability in the ISP networks (e.g., when the access network > cannot be upgraded [which seems to have similar requirements as 3GPP]) > would be highly appreciated. > > Thanks! > > (hat off) > > -- 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 Thu Sep 2 10:01:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04340 for ; Thu, 2 Sep 2004 10:01:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2s7c-000Ass-Te for v6ops-data@psg.com; Thu, 02 Sep 2004 13:59:28 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2s7R-000ArE-3b for v6ops@ops.ietf.org; Thu, 02 Sep 2004 13:59:17 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000393454.msg for ; Thu, 02 Sep 2004 16:03:09 +0200 Message-ID: <166801c490f5$03cfbdf0$3220dfa9@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: REVIEW NEEDED: zeroconf requirements document Date: Fri, 3 Sep 2004 01:59:03 +1200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Thu, 02 Sep 2004 16:03:09 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 169.223.32.50 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Thu, 02 Sep 2004 16:03:12 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, There is also a direct link as http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-01.txt. Regards, Jordi ----- Original Message -----=20 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" ; Sent: Friday, September 03, 2004 12:56 AM Subject: RE: REVIEW NEEDED: zeroconf requirements document > Dear All, >=20 > The promised revised version, > draft-nielsen-v6ops-zeroconf-goals-01.txt, > can be found on the following link: >=20 > http://www.v6ops.euro6ix.net/zerotunnel.php# >=20 > On behalf of the authors I would like to echo Pekka's > request for a review of this work. >=20 > Feedback are requested on the general scope > of the documents as well as on the particular set of > individual goals put forward. >=20 > Please scrutinize. >=20 > BR, Karen >=20 > The drafts has been submitted to the IDs,=20 > but it will probably take a while for it to appear. >=20 > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > > Behalf Of Pekka Savola > > Sent: Wednesday, September 01, 2004 12:29 PM > > To: v6ops@ops.ietf.org > > Subject: Re: REVIEW NEEDED: zeroconf requirements document > >=20 > >=20 > > (co-chair hat on) > >=20 > > The document editor just said that a revised version, addressing the > > input received so far, could be available for tomorrow. > >=20 > > So, please hold off the review until the new revision has been made > > available (-01 version). Let's shift the review DL by one day, to 7th > > September. > >=20 > > Thanks to the surprisingly active document editor and authors! :-) > >=20 > > (hat off) > >=20 > > On Wed, 1 Sep 2004, Pekka Savola wrote: > > > (co-chair hat on) > > >=20 > > > If you recall from the IETF60 meeting, we set out a couple of > > > milestonoes and deadlines to make progress well before the next > > > meeting -- and now the planning and scheduling for IETF61=20 > > has already > > > started... > > >=20 > > > We need to get more input especially on: > > >=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-00.txt > >=20 > > Please read it and send feedback on the list. Please do this as soon > > as possible but on 6th September at the latest. > >=20 > > In particular, opinions on whether the document should include the > > applicability in the ISP networks (e.g., when the access network > > cannot be upgraded [which seems to have similar requirements as 3GPP]) =20 > > would be highly appreciated. > >=20 > > Thanks! > >=20 > > (hat off) > >=20 > >=20 >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Sep 2 14:51:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27392 for ; Thu, 2 Sep 2004 14:51:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2wej-0007fA-9d for v6ops-data@psg.com; Thu, 02 Sep 2004 18:49:57 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2weY-0007du-Gl for v6ops@ops.ietf.org; Thu, 02 Sep 2004 18:49:46 +0000 Received: from [128.9.168.57] (tnn.isi.edu [128.9.168.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i82In9J21447; Thu, 2 Sep 2004 11:49:09 -0700 (PDT) Message-ID: <41376B22.1070401@isi.edu> Date: Thu, 02 Sep 2004 11:49:06 -0700 From: Yu-Shun Wang User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: zeroconf requirements document References: <166801c490f5$03cfbdf0$3220dfa9@consulintel.es> In-Reply-To: <166801c490f5$03cfbdf0$3220dfa9@consulintel.es> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060602010000000103020609" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: yushunwa@isi.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms060602010000000103020609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit JORDI PALET MARTINEZ wrote: > Hi all, > > There is also a direct link as http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-01.txt. Hi, Is it just me or are there non-ASCII characters in the doc file? Thanks, yushun > Regards, > Jordi > > ----- Original Message ----- > From: "Karen E. Nielsen (AH/TED)" > To: "'Pekka Savola'" ; > Sent: Friday, September 03, 2004 12:56 AM > Subject: RE: REVIEW NEEDED: zeroconf requirements document > > > >>Dear All, >> >>The promised revised version, >>draft-nielsen-v6ops-zeroconf-goals-01.txt, >>can be found on the following link: >> >>http://www.v6ops.euro6ix.net/zerotunnel.php# >> >>On behalf of the authors I would like to echo Pekka's >>request for a review of this work. >> >>Feedback are requested on the general scope >>of the documents as well as on the particular set of >>individual goals put forward. >> >>Please scrutinize. >> >>BR, Karen >> >>The drafts has been submitted to the IDs, >>but it will probably take a while for it to appear. >> >> >>>-----Original Message----- >>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On >>>Behalf Of Pekka Savola >>>Sent: Wednesday, September 01, 2004 12:29 PM >>>To: v6ops@ops.ietf.org >>>Subject: Re: REVIEW NEEDED: zeroconf requirements document >>> >>> >>>(co-chair hat on) >>> >>>The document editor just said that a revised version, addressing the >>>input received so far, could be available for tomorrow. >>> >>>So, please hold off the review until the new revision has been made >>>available (-01 version). Let's shift the review DL by one day, to 7th >>>September. >>> >>>Thanks to the surprisingly active document editor and authors! :-) >>> >>>(hat off) >>> >>>On Wed, 1 Sep 2004, Pekka Savola wrote: >>> >>>>(co-chair hat on) >>>> >>>>If you recall from the IETF60 meeting, we set out a couple of >>>>milestonoes and deadlines to make progress well before the next >>>>meeting -- and now the planning and scheduling for IETF61 >>> >>>has already >>> >>>>started... >>>> >>>>We need to get more input especially on: >>>> >>>> >> >>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-00.txt >> >>>Please read it and send feedback on the list. Please do this as soon >>>as possible but on 6th September at the latest. >>> >>>In particular, opinions on whether the document should include the >>>applicability in the ISP networks (e.g., when the access network >>>cannot be upgraded [which seems to have similar requirements as 3GPP]) >>>would be highly appreciated. >>> >>>Thanks! >>> >>>(hat off) >>> >>> >> >>-- >>Pekka Savola "You each name yourselves king, yet the >>Netcore Oy kingdom bleeds." >>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > -- Yu-Shun Wang USC Information Sciences Institute --------------ms060602010000000103020609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICAwuzTDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5U xhl7Ij0hjHYl8ZRZc0D9m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+up D9fxexuSRzhQeqv+EEmhjJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7H Gw6HoUbYnPuLFP8YRI3A72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQ DyM5visEsRhwR8LegLn8UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoS HAV5OavL0zEO4mSug5bLSpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vs ott5PU1mjm2Mnh4jgjhmqZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99N yJJooUql3crtUKcfxCsukuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAxcwggKAoAMCAQICAwuz TDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5Uxhl7Ij0hjHYl8ZRZc0D9 m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+upD9fxexuSRzhQeqv+EEmh jJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7HGw6HoUbYnPuLFP8YRI3A 72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQDyM5visEsRhwR8LegLn8 UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoSHAV5OavL0zEO4mSug5bL SpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vsott5PU1mjm2Mnh4jgjhm qZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99NyJJooUql3crtUKcfxCsu kuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIID NwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID C7NMMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA0MDkwMjE4NDkwNlowIwYJKoZIhvcNAQkEMRYEFPD+qeq21NA9//01zmjGtXfA v+DOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLs0wwegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC7NMMA0GCSqGSIb3DQEBAQUABIIBAIYfTcWO7KGItQhqxxLgXscIoayGcK+qhUVl KYENB6hZ/jZYX+YfPYc7Py7OMA6z+PcnDJADW/yPA799G1C8/tRTLkWQbC0aY7L+0L7wHny8 EeSriqPU77jgZEs4wJLsfDLhR15mH4izI/ioegzjHgoyFGVvo32Ikd06vsVzCa2CvOJUlcT9 v8mtsimhlMFaRlTu4um2jb8OBY2Gc0h6QRw7JQACN9POMmBQJibqrJPUj5lmhaBeBLGDdH9K iM4y/xcfhhRMukS+bCUjxoyh0OlIToF4odSipxgf/I6L9n0tALGEYQKN0wJX+J7qv1VVk15y RdSgM0+szqIOzzdv90MAAAAAAAA= --------------ms060602010000000103020609-- From owner-v6ops@ops.ietf.org Thu Sep 2 15:33:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00797 for ; Thu, 2 Sep 2004 15:33:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2xKD-000FjD-Uu for v6ops-data@psg.com; Thu, 02 Sep 2004 19:32:49 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2xK0-000Fha-Hp for v6ops@ops.ietf.org; Thu, 02 Sep 2004 19:32:36 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i82JWZAh026045 for ; Thu, 2 Sep 2004 21:32:35 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Sep 2004 21:32:35 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id R87D6K08; Thu, 2 Sep 2004 21:32:35 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Sep 2004 21:32:35 +0200 Message-ID: X-Sybari-Trust: 5bed4cef 477d8de1 f882b225 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Yu-Shun Wang'" , v6ops@ops.ietf.org Cc: JORDI PALET MARTINEZ Subject: RE: REVIEW NEEDED: zeroconf requirements document Date: Thu, 2 Sep 2004 21:32:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Sep 2004 19:32:35.0174 (UTC) FILETIME=[991A5860:01C49123] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk All, Please use the non-direct link http://www.v6ops.euro6ix.net/zerotunnel.php# to retrieve the document (draft-nielsen-v6ops-zeroconf-goals-01.txt). I apologize for the inconvenience. Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Yu-Shun Wang > Sent: Thursday, September 02, 2004 8:49 PM > To: JORDI PALET MARTINEZ > Cc: v6ops@ops.ietf.org > Subject: Re: REVIEW NEEDED: zeroconf requirements document > > > JORDI PALET MARTINEZ wrote: > > Hi all, > > > > There is also a direct link as > http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf > -goals-01.txt. > > Hi, > > Is it just me or are there non-ASCII characters in the doc file? > > Thanks, > > yushun > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: "Karen E. Nielsen (AH/TED)" > > To: "'Pekka Savola'" ; > > Sent: Friday, September 03, 2004 12:56 AM > > Subject: RE: REVIEW NEEDED: zeroconf requirements document > > > > > > > >>Dear All, > >> > >>The promised revised version, > >>draft-nielsen-v6ops-zeroconf-goals-01.txt, > >>can be found on the following link: > >> > >>http://www.v6ops.euro6ix.net/zerotunnel.php# > >> > >>On behalf of the authors I would like to echo Pekka's > >>request for a review of this work. > >> > >>Feedback are requested on the general scope > >>of the documents as well as on the particular set of > >>individual goals put forward. > >> > >>Please scrutinize. > >> > >>BR, Karen > >> > >>The drafts has been submitted to the IDs, > >>but it will probably take a while for it to appear. > >> > >> > >>>-----Original Message----- > >>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>>Behalf Of Pekka Savola > >>>Sent: Wednesday, September 01, 2004 12:29 PM > >>>To: v6ops@ops.ietf.org > >>>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >>> > >>> > >>>(co-chair hat on) > >>> > >>>The document editor just said that a revised version, > addressing the > >>>input received so far, could be available for tomorrow. > >>> > >>>So, please hold off the review until the new revision has been made > >>>available (-01 version). Let's shift the review DL by one > day, to 7th > >>>September. > >>> > >>>Thanks to the surprisingly active document editor and authors! :-) > >>> > >>>(hat off) > >>> > >>>On Wed, 1 Sep 2004, Pekka Savola wrote: > >>> > >>>>(co-chair hat on) > >>>> > >>>>If you recall from the IETF60 meeting, we set out a couple of > >>>>milestonoes and deadlines to make progress well before the next > >>>>meeting -- and now the planning and scheduling for IETF61 > >>> > >>>has already > >>> > >>>>started... > >>>> > >>>>We need to get more input especially on: > >>>> > >>>> > >> > >>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zero conf-goals-00.txt >> >>>Please read it and send feedback on the list. Please do this as soon >>>as possible but on 6th September at the latest. >>> >>>In particular, opinions on whether the document should include the >>>applicability in the ISP networks (e.g., when the access network >>>cannot be upgraded [which seems to have similar requirements as 3GPP]) >>>would be highly appreciated. >>> >>>Thanks! >>> >>>(hat off) >>> >>> >> >>-- >>Pekka Savola "You each name yourselves king, yet the >>Netcore Oy kingdom bleeds." >>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > -- Yu-Shun Wang USC Information Sciences Institute From owner-v6ops@ops.ietf.org Thu Sep 2 15:52:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02165 for ; Thu, 2 Sep 2004 15:52:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2xcA-000JJB-H3 for v6ops-data@psg.com; Thu, 02 Sep 2004 19:51:22 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2xbb-000JDc-JZ for v6ops@ops.ietf.org; Thu, 02 Sep 2004 19:50:47 +0000 Received: from [128.9.168.57] (tnn.isi.edu [128.9.168.57]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i82JnpJ07997; Thu, 2 Sep 2004 12:49:51 -0700 (PDT) Message-ID: <4137795F.2040700@isi.edu> Date: Thu, 02 Sep 2004 12:49:51 -0700 From: Yu-Shun Wang User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Karen E. Nielsen (AH/TED)" CC: v6ops@ops.ietf.org, JORDI PALET MARTINEZ Subject: Re: REVIEW NEEDED: zeroconf requirements document References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070309050202000302020703" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: yushunwa@isi.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms070309050202000302020703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Karen E. Nielsen (AH/TED) wrote: > All, > > Please use the non-direct link > http://www.v6ops.euro6ix.net/zerotunnel.php# > to retrieve the document (draft-nielsen-v6ops-zeroconf-goals-01.txt). Hi, Karen, That's how I got it. The -00 is fine, but could you check the -01 file again? Thanks, yushun > I apologize for the inconvenience. > > Karen > > >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On >>Behalf Of Yu-Shun Wang >>Sent: Thursday, September 02, 2004 8:49 PM >>To: JORDI PALET MARTINEZ >>Cc: v6ops@ops.ietf.org >>Subject: Re: REVIEW NEEDED: zeroconf requirements document >> >> >>JORDI PALET MARTINEZ wrote: >> >>>Hi all, >>> >>>There is also a direct link as >> >>http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf >>-goals-01.txt. >> >>Hi, >> >>Is it just me or are there non-ASCII characters in the doc file? >> >>Thanks, >> >>yushun >> >> >>>Regards, >>>Jordi >>> >>>----- Original Message ----- >>>From: "Karen E. Nielsen (AH/TED)" >>>To: "'Pekka Savola'" ; >>>Sent: Friday, September 03, 2004 12:56 AM >>>Subject: RE: REVIEW NEEDED: zeroconf requirements document >>> >>> >>> >>> >>>>Dear All, >>>> >>>>The promised revised version, >>>>draft-nielsen-v6ops-zeroconf-goals-01.txt, >>>>can be found on the following link: >>>> >>>>http://www.v6ops.euro6ix.net/zerotunnel.php# >>>> >>>>On behalf of the authors I would like to echo Pekka's >>>>request for a review of this work. >>>> >>>>Feedback are requested on the general scope >>>>of the documents as well as on the particular set of >>>>individual goals put forward. >>>> >>>>Please scrutinize. >>>> >>>>BR, Karen >>>> >>>>The drafts has been submitted to the IDs, >>>>but it will probably take a while for it to appear. >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On >>>>>Behalf Of Pekka Savola >>>>>Sent: Wednesday, September 01, 2004 12:29 PM >>>>>To: v6ops@ops.ietf.org >>>>>Subject: Re: REVIEW NEEDED: zeroconf requirements document >>>>> >>>>> >>>>>(co-chair hat on) >>>>> >>>>>The document editor just said that a revised version, >> >>addressing the >> >>>>>input received so far, could be available for tomorrow. >>>>> >>>>>So, please hold off the review until the new revision has been made >>>>>available (-01 version). Let's shift the review DL by one >> >>day, to 7th >> >>>>>September. >>>>> >>>>>Thanks to the surprisingly active document editor and authors! :-) >>>>> >>>>>(hat off) >>>>> >>>>>On Wed, 1 Sep 2004, Pekka Savola wrote: >>>>> >>>>> >>>>>>(co-chair hat on) >>>>>> >>>>>>If you recall from the IETF60 meeting, we set out a couple of >>>>>>milestonoes and deadlines to make progress well before the next >>>>>>meeting -- and now the planning and scheduling for IETF61 >>>>> >>>>>has already >>>>> >>>>> >>>>>>started... >>>>>> >>>>>>We need to get more input especially on: >>>>>> >>>>>> >>>> >>>>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zero > > conf-goals-00.txt > >>>>Please read it and send feedback on the list. Please do this as soon >>>>as possible but on 6th September at the latest. >>>> >>>>In particular, opinions on whether the document should include the >>>>applicability in the ISP networks (e.g., when the access network >>>>cannot be upgraded [which seems to have similar requirements as 3GPP]) >>>>would be highly appreciated. >>>> >>>>Thanks! >>>> >>>>(hat off) >>>> >>>> >>> >>>-- >>>Pekka Savola "You each name yourselves king, yet the >>>Netcore Oy kingdom bleeds." >>>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >>> > > >>********************************** >>Madrid 2003 Global IPv6 Summit >>Presentations and videos on line at: >>http://www.ipv6-es.com >> >>This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. >> >> >> > > > -- Yu-Shun Wang USC Information Sciences Institute --------------ms070309050202000302020703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICAwuzTDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2 WjB6MQ0wCwYDVQQEEwRXYW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVu IFdhbmcxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEW EHl1c2h1bndhQHVzYy5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5U xhl7Ij0hjHYl8ZRZc0D9m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+up D9fxexuSRzhQeqv+EEmhjJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7H Gw6HoUbYnPuLFP8YRI3A72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQ DyM5visEsRhwR8LegLn8UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoS HAV5OavL0zEO4mSug5bLSpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQm MCSBEHl1c2h1bndhQGlzaS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vs ott5PU1mjm2Mnh4jgjhmqZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99N yJJooUql3crtUKcfxCsukuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAxcwggKAoAMCAQICAwuz TDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwHhcNMDQwMjEyMDcwNzM2WhcNMDUwMjExMDcwNzM2WjB6MQ0wCwYDVQQEEwRX YW5nMRAwDgYDVQQqEwdZdS1TaHVuMRUwEwYDVQQDEwxZdS1TaHVuIFdhbmcxHzAdBgkqhkiG 9w0BCQEWEHl1c2h1bndhQGlzaS5lZHUxHzAdBgkqhkiG9w0BCQEWEHl1c2h1bndhQHVzYy5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc8n5Uxhl7Ij0hjHYl8ZRZc0D9 m/dX9elXEi+F4m8BjcrySYYNxiAUAxb6iB7aCskyxmYpxDRgC+upD9fxexuSRzhQeqv+EEmh jJ14IEx3JfGT0Mnuexef5UfOjf8t2zJLTMp2Z6ZJNZhm0d3OTX7HGw6HoUbYnPuLFP8YRI3A 72Gyjo9qlajq2Fv84ZpdRwt+plDk6czfawPMpptPw7RVNQTRhadQDyM5visEsRhwR8LegLn8 UqtwomeiauxNSbNrUJI3vm8Q8JZFKQWZlrod/I3Ud7P4zU6qQXoSHAV5OavL0zEO4mSug5bL SpfSoumBg6CvYbPEz4mUPJ3JGBnbAgMBAAGjPzA9MC0GA1UdEQQmMCSBEHl1c2h1bndhQGlz aS5lZHWBEHl1c2h1bndhQHVzYy5lZHUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQAUuycfrv876o8eccQGgl7AWxEottLDXHxL4W9XxL2rPMER88Vsott5PU1mjm2Mnh4jgjhm qZaofReeTbLQaCbgqgdyR4ZESZjbmE7e8tWpe9blMjcCTpeVI99NyJJooUql3crtUKcfxCsu kuh200E3Aaw8PW6KY5N3HG45ISpF8zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIID NwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID C7NMMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTA0MDkwMjE5NDk1MVowIwYJKoZIhvcNAQkEMRYEFJ2qm4jR9DnMzOfhEZpymrxE R5QjMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMLs0wwegYLKoZI hvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIDC7NMMA0GCSqGSIb3DQEBAQUABIIBAEAhSJckElFpE/gvuwIVcY1SpPWZI2NqyyyP G/mCTwscmyDrqQ4mua/t6/xt/e/05U/Xb/RZqoRLb1RmndBfWdO8I+yJtVu73qcZxNn/w27B WheANDaFWG+oUdFeW/5TWWW28mcWBTCmI0XiOpMer5V53mbgBcVNZx1k+72an1fqofJj8AHU 8VS7XaAU7TrRDMKRwfdqF7xiMfBj7yMyNjapDbYeJFjkqOKvZdRboK6AKC6sSNLCmUnnEd1+ EIku4FKEgjrNaLyQyrOVT4NPPeWv3VXiaNSwQFM+6zwO5lyfYoXFlqps7frJK2DeFiGKVGL1 Aos9Z5ygT+P0VWUiTH8AAAAAAAA= --------------ms070309050202000302020703-- From owner-v6ops@ops.ietf.org Thu Sep 2 18:18:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17329 for ; Thu, 2 Sep 2004 18:18:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C2zsN-000L4Y-CF for v6ops-data@psg.com; Thu, 02 Sep 2004 22:16:15 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C2zsA-000KyW-Rs for v6ops@ops.ietf.org; Thu, 02 Sep 2004 22:16:03 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000397549.msg for ; Fri, 03 Sep 2004 00:19:57 +0200 Message-ID: <1a0901c4913a$69ab6f30$3220dfa9@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <4137795F.2040700@isi.edu> Subject: Re: REVIEW NEEDED: zeroconf requirements document Date: Fri, 3 Sep 2004 10:15:50 +1200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 03 Sep 2004 00:19:57 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 169.223.32.50 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Fri, 03 Sep 2004 00:19:58 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Yushun, Sorry, yes you're right it will make no difference, something very weird happened. Now is solved. http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-01.txt (at least is working for me, both IPv4 and IPv6). But also it has already been published "officially": http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-01.txt Regards, Jordi ----- Original Message -----=20 From: "Yu-Shun Wang" To: "Karen E. Nielsen (AH/TED)" Cc: ; "JORDI PALET MARTINEZ" Sent: Friday, September 03, 2004 7:49 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document > Karen E. Nielsen (AH/TED) wrote: > > All, > >=20 > > Please use the non-direct link > > http://www.v6ops.euro6ix.net/zerotunnel.php# > > to retrieve the document (draft-nielsen-v6ops-zeroconf-goals-01.txt). >=20 > Hi, Karen, >=20 > That's how I got it. The -00 is fine, but could you check > the -01 file again? >=20 > Thanks, >=20 > yushun >=20 > > I apologize for the inconvenience. > >=20 > > Karen > >=20 > >=20 > >>-----Original Message----- > >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>Behalf Of Yu-Shun Wang > >>Sent: Thursday, September 02, 2004 8:49 PM > >>To: JORDI PALET MARTINEZ > >>Cc: v6ops@ops.ietf.org > >>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >> > >> > >>JORDI PALET MARTINEZ wrote: > >> > >>>Hi all, > >>> > >>>There is also a direct link as=20 > >> > >>http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf > >>-goals-01.txt. > >> > >>Hi, > >> > >>Is it just me or are there non-ASCII characters in the doc file? > >> > >>Thanks, > >> > >>yushun > >> > >> > >>>Regards, > >>>Jordi > >>> > >>>----- Original Message -----=20 > >>>From: "Karen E. Nielsen (AH/TED)" > >>>To: "'Pekka Savola'" ; > >>>Sent: Friday, September 03, 2004 12:56 AM > >>>Subject: RE: REVIEW NEEDED: zeroconf requirements document > >>> > >>> > >>> > >>> > >>>>Dear All, > >>>> > >>>>The promised revised version, > >>>>draft-nielsen-v6ops-zeroconf-goals-01.txt, > >>>>can be found on the following link: > >>>> > >>>>http://www.v6ops.euro6ix.net/zerotunnel.php# > >>>> > >>>>On behalf of the authors I would like to echo Pekka's > >>>>request for a review of this work. > >>>> > >>>>Feedback are requested on the general scope > >>>>of the documents as well as on the particular set of > >>>>individual goals put forward. > >>>> > >>>>Please scrutinize. > >>>> > >>>>BR, Karen > >>>> > >>>>The drafts has been submitted to the IDs,=20 > >>>>but it will probably take a while for it to appear. > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>>>>Behalf Of Pekka Savola > >>>>>Sent: Wednesday, September 01, 2004 12:29 PM > >>>>>To: v6ops@ops.ietf.org > >>>>>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >>>>> > >>>>> > >>>>>(co-chair hat on) > >>>>> > >>>>>The document editor just said that a revised version,=20 > >> > >>addressing the > >> > >>>>>input received so far, could be available for tomorrow. > >>>>> > >>>>>So, please hold off the review until the new revision has been made > >>>>>available (-01 version). Let's shift the review DL by one=20 > >> > >>day, to 7th > >> > >>>>>September. > >>>>> > >>>>>Thanks to the surprisingly active document editor and authors! :-) > >>>>> > >>>>>(hat off) > >>>>> > >>>>>On Wed, 1 Sep 2004, Pekka Savola wrote: > >>>>> > >>>>> > >>>>>>(co-chair hat on) > >>>>>> > >>>>>>If you recall from the IETF60 meeting, we set out a couple of > >>>>>>milestonoes and deadlines to make progress well before the next > >>>>>>meeting -- and now the planning and scheduling for IETF61=20 > >>>>> > >>>>>has already > >>>>> > >>>>> > >>>>>>started... > >>>>>> > >>>>>>We need to get more input especially on: > >>>>>> > >>>>>> > >>>> > >>>>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zero > >=20 > > conf-goals-00.txt > >=20 > >>>>Please read it and send feedback on the list. Please do this as soon > >>>>as possible but on 6th September at the latest. > >>>> > >>>>In particular, opinions on whether the document should include the > >>>>applicability in the ISP networks (e.g., when the access network > >>>>cannot be upgraded [which seems to have similar requirements as 3GPP]) =20 > >>>>would be highly appreciated. > >>>> > >>>>Thanks! > >>>> > >>>>(hat off) > >>>> > >>>> > >>> > >>>--=20 > >>>Pekka Savola "You each name yourselves king, yet the > >>>Netcore Oy kingdom bleeds." > >>>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >>> > >=20 > >=20 > >>********************************** > >>Madrid 2003 Global IPv6 Summit > >>Presentations and videos on line at: > >>http://www.ipv6-es.com > >> > >>This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > >> > >> > >> > >=20 > >=20 > >=20 >=20 >=20 > --=20 > Yu-Shun Wang > USC Information Sciences Institute >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Sep 3 04:37:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07600 for ; Fri, 3 Sep 2004 04:37:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C39WU-0009aP-FW for v6ops-data@psg.com; Fri, 03 Sep 2004 08:34:18 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C39WA-0009UO-1j for v6ops@ops.ietf.org; Fri, 03 Sep 2004 08:33:58 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3G000V9IGJ99@mailout2.samsung.com> for v6ops@ops.ietf.org; Fri, 03 Sep 2004 17:33:56 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3G00BS1IG60R@mailout2.samsung.com> for v6ops@ops.ietf.org; Fri, 03 Sep 2004 17:33:42 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3G008AQIG4J4@mmp1.samsung.com> for v6ops@ops.ietf.org; Fri, 03 Sep 2004 17:33:42 +0900 (KST) Date: Fri, 03 Sep 2004 14:03:25 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: REVIEW NEEDED: zeroconf requirements document To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Reply-to: Radhakrishnan Suryanarayanan Message-id: <00ee01c49190$af50e910$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4137795F.2040700@isi.edu> <1a0901c4913a$69ab6f30$3220dfa9@consulintel.es> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Jordi, Why is there a special emphasis on 3GPP in this document? Regards Radhakrishnan ----- Original Message ----- From: "JORDI PALET MARTINEZ" To: Sent: Friday, September 03, 2004 3:45 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document Hi Yushun, Sorry, yes you're right it will make no difference, something very weird happened. Now is solved. http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-01.txt (at least is working for me, both IPv4 and IPv6). But also it has already been published "officially": http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-01.txt Regards, Jordi ----- Original Message ----- From: "Yu-Shun Wang" To: "Karen E. Nielsen (AH/TED)" Cc: ; "JORDI PALET MARTINEZ" Sent: Friday, September 03, 2004 7:49 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document > Karen E. Nielsen (AH/TED) wrote: > > All, > > > > Please use the non-direct link > > http://www.v6ops.euro6ix.net/zerotunnel.php# > > to retrieve the document (draft-nielsen-v6ops-zeroconf-goals-01.txt). > > Hi, Karen, > > That's how I got it. The -00 is fine, but could you check > the -01 file again? > > Thanks, > > yushun > > > I apologize for the inconvenience. > > > > Karen > > > > > >>-----Original Message----- > >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>Behalf Of Yu-Shun Wang > >>Sent: Thursday, September 02, 2004 8:49 PM > >>To: JORDI PALET MARTINEZ > >>Cc: v6ops@ops.ietf.org > >>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >> > >> > >>JORDI PALET MARTINEZ wrote: > >> > >>>Hi all, > >>> > >>>There is also a direct link as > >> > >>http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf > >>-goals-01.txt. > >> > >>Hi, > >> > >>Is it just me or are there non-ASCII characters in the doc file? > >> > >>Thanks, > >> > >>yushun > >> > >> > >>>Regards, > >>>Jordi > >>> > >>>----- Original Message ----- > >>>From: "Karen E. Nielsen (AH/TED)" > >>>To: "'Pekka Savola'" ; > >>>Sent: Friday, September 03, 2004 12:56 AM > >>>Subject: RE: REVIEW NEEDED: zeroconf requirements document > >>> > >>> > >>> > >>> > >>>>Dear All, > >>>> > >>>>The promised revised version, > >>>>draft-nielsen-v6ops-zeroconf-goals-01.txt, > >>>>can be found on the following link: > >>>> > >>>>http://www.v6ops.euro6ix.net/zerotunnel.php# > >>>> > >>>>On behalf of the authors I would like to echo Pekka's > >>>>request for a review of this work. > >>>> > >>>>Feedback are requested on the general scope > >>>>of the documents as well as on the particular set of > >>>>individual goals put forward. > >>>> > >>>>Please scrutinize. > >>>> > >>>>BR, Karen > >>>> > >>>>The drafts has been submitted to the IDs, > >>>>but it will probably take a while for it to appear. > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>>>>Behalf Of Pekka Savola > >>>>>Sent: Wednesday, September 01, 2004 12:29 PM > >>>>>To: v6ops@ops.ietf.org > >>>>>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >>>>> > >>>>> > >>>>>(co-chair hat on) > >>>>> > >>>>>The document editor just said that a revised version, > >> > >>addressing the > >> > >>>>>input received so far, could be available for tomorrow. > >>>>> > >>>>>So, please hold off the review until the new revision has been made > >>>>>available (-01 version). Let's shift the review DL by one > >> > >>day, to 7th > >> > >>>>>September. > >>>>> > >>>>>Thanks to the surprisingly active document editor and authors! :-) > >>>>> > >>>>>(hat off) > >>>>> > >>>>>On Wed, 1 Sep 2004, Pekka Savola wrote: > >>>>> > >>>>> > >>>>>>(co-chair hat on) > >>>>>> > >>>>>>If you recall from the IETF60 meeting, we set out a couple of > >>>>>>milestonoes and deadlines to make progress well before the next > >>>>>>meeting -- and now the planning and scheduling for IETF61 > >>>>> > >>>>>has already > >>>>> > >>>>> > >>>>>>started... > >>>>>> > >>>>>>We need to get more input especially on: > >>>>>> > >>>>>> > >>>> > >>>>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zero > > > > conf-goals-00.txt > > > >>>>Please read it and send feedback on the list. Please do this as soon > >>>>as possible but on 6th September at the latest. > >>>> > >>>>In particular, opinions on whether the document should include the > >>>>applicability in the ISP networks (e.g., when the access network > >>>>cannot be upgraded [which seems to have similar requirements as 3GPP]) > >>>>would be highly appreciated. > >>>> > >>>>Thanks! > >>>> > >>>>(hat off) > >>>> > >>>> > >>> > >>>-- > >>>Pekka Savola "You each name yourselves king, yet the > >>>Netcore Oy kingdom bleeds." > >>>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >>> > > > > > >>********************************** > >>Madrid 2003 Global IPv6 Summit > >>Presentations and videos on line at: > >>http://www.ipv6-es.com > >> > >>This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > >> > >> > >> > > > > > > > > > -- > Yu-Shun Wang > USC Information Sciences Institute > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Sep 3 04:56:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08368 for ; Fri, 3 Sep 2004 04:56:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C39rL-000D5m-7K for v6ops-data@psg.com; Fri, 03 Sep 2004 08:55:51 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C39qt-000D1z-Tk for v6ops@ops.ietf.org; Fri, 03 Sep 2004 08:55:24 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i838tLj25133 for ; Fri, 3 Sep 2004 11:55:21 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 11:55:00 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i838t0Pc016375 for ; Fri, 3 Sep 2004 11:55:00 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00FgXdNm; Fri, 03 Sep 2004 11:53:37 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i838rVS11509 for ; Fri, 3 Sep 2004 11:53:31 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 11:53:23 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 11:53:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: REVIEW NEEDED: zeroconf requirements document Date: Fri, 3 Sep 2004 11:53:24 +0300 Message-ID: <4255703385E781428653E1DEE230980D1514F4@esebe054.ntc.nokia.com> Thread-Topic: REVIEW NEEDED: zeroconf requirements document Thread-Index: AcSRkfi5Yp7NhVpHQiCiqZB10fZLWAAABlcQAABMZEA= From: To: X-OriginalArrivalTime: 03 Sep 2004 08:53:24.0278 (UTC) FILETIME=[7899C560:01C49193] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Sending this also on the v6ops list, the mail below was sent only to = Radhakrishnan... -jw- -----Original Message----- From: Wiljakka Juha (Nokia-M/Tampere)=20 Sent: 03 September, 2004 11:52 To: 'Radhakrishnan Suryanarayanan' Subject: RE: REVIEW NEEDED: zeroconf requirements document Hi, Radhakrishnan! It is because 3GPP Analysis www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt (see sections 3.1 and 6) has found a need for a simple tunneling mechanism. Commission has been = given by the ADs to write down a minimal set of requirements required = for 3GPP environment automatic tunneling. This was discussed in IETF#60 = v6ops meeting. However, this document *may* be applicable for other environments too. BR, -Juha W.- -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Radhakrishnan Suryanarayanan Sent: 03 September, 2004 11:33 To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: zeroconf requirements document Hi Jordi, Why is there a special emphasis on 3GPP in this document? Regards Radhakrishnan ----- Original Message -----=20 From: "JORDI PALET MARTINEZ" To: Sent: Friday, September 03, 2004 3:45 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document Hi Yushun, Sorry, yes you're right it will make no difference, something very weird happened. Now is solved. http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-01.t= xt (at least is working for me, both IPv4 and IPv6). But also it has already been published "officially": http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-01= .txt Regards, Jordi ----- Original Message -----=20 From: "Yu-Shun Wang" To: "Karen E. Nielsen (AH/TED)" Cc: ; "JORDI PALET MARTINEZ" Sent: Friday, September 03, 2004 7:49 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document > Karen E. Nielsen (AH/TED) wrote: > > All, > > > > Please use the non-direct link > > http://www.v6ops.euro6ix.net/zerotunnel.php# > > to retrieve the document = (draft-nielsen-v6ops-zeroconf-goals-01.txt). > > Hi, Karen, > > That's how I got it. The -00 is fine, but could you check > the -01 file again? > > Thanks, > > yushun > > > I apologize for the inconvenience. > > > > Karen > > > > > >>-----Original Message----- > >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>Behalf Of Yu-Shun Wang > >>Sent: Thursday, September 02, 2004 8:49 PM > >>To: JORDI PALET MARTINEZ > >>Cc: v6ops@ops.ietf.org > >>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >> > >> > >>JORDI PALET MARTINEZ wrote: > >> > >>>Hi all, > >>> > >>>There is also a direct link as > >> > >>http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf > >>-goals-01.txt. > >> > >>Hi, > >> > >>Is it just me or are there non-ASCII characters in the doc file? > >> > >>Thanks, > >> > >>yushun > >> > >> > >>>Regards, > >>>Jordi > >>> > >>>----- Original Message -----=20 > >>>From: "Karen E. Nielsen (AH/TED)" > >>>To: "'Pekka Savola'" ; > >>>Sent: Friday, September 03, 2004 12:56 AM > >>>Subject: RE: REVIEW NEEDED: zeroconf requirements document > >>> > >>> > >>> > >>> > >>>>Dear All, > >>>> > >>>>The promised revised version, > >>>>draft-nielsen-v6ops-zeroconf-goals-01.txt, > >>>>can be found on the following link: > >>>> > >>>>http://www.v6ops.euro6ix.net/zerotunnel.php# > >>>> > >>>>On behalf of the authors I would like to echo Pekka's > >>>>request for a review of this work. > >>>> > >>>>Feedback are requested on the general scope > >>>>of the documents as well as on the particular set of > >>>>individual goals put forward. > >>>> > >>>>Please scrutinize. > >>>> > >>>>BR, Karen > >>>> > >>>>The drafts has been submitted to the IDs, > >>>>but it will probably take a while for it to appear. > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: owner-v6ops@ops.ietf.org = [mailto:owner-v6ops@ops.ietf.org]On > >>>>>Behalf Of Pekka Savola > >>>>>Sent: Wednesday, September 01, 2004 12:29 PM > >>>>>To: v6ops@ops.ietf.org > >>>>>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >>>>> > >>>>> > >>>>>(co-chair hat on) > >>>>> > >>>>>The document editor just said that a revised version, > >> > >>addressing the > >> > >>>>>input received so far, could be available for tomorrow. > >>>>> > >>>>>So, please hold off the review until the new revision has been = made > >>>>>available (-01 version). Let's shift the review DL by one > >> > >>day, to 7th > >> > >>>>>September. > >>>>> > >>>>>Thanks to the surprisingly active document editor and authors! = :-) > >>>>> > >>>>>(hat off) > >>>>> > >>>>>On Wed, 1 Sep 2004, Pekka Savola wrote: > >>>>> > >>>>> > >>>>>>(co-chair hat on) > >>>>>> > >>>>>>If you recall from the IETF60 meeting, we set out a couple of > >>>>>>milestonoes and deadlines to make progress well before the next > >>>>>>meeting -- and now the planning and scheduling for IETF61 > >>>>> > >>>>>has already > >>>>> > >>>>> > >>>>>>started... > >>>>>> > >>>>>>We need to get more input especially on: > >>>>>> > >>>>>> > >>>> > >>>>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zero > > > > conf-goals-00.txt > > > >>>>Please read it and send feedback on the list. Please do this as = soon > >>>>as possible but on 6th September at the latest. > >>>> > >>>>In particular, opinions on whether the document should include the > >>>>applicability in the ISP networks (e.g., when the access network > >>>>cannot be upgraded [which seems to have similar requirements as = 3GPP]) > >>>>would be highly appreciated. > >>>> > >>>>Thanks! > >>>> > >>>>(hat off) > >>>> > >>>> > >>> > >>>--=20 > >>>Pekka Savola "You each name yourselves king, yet = the > >>>Netcore Oy kingdom bleeds." > >>>Systems. Networks. Security. -- George R.R. Martin: A Clash of = Kings > >>> > > > > > >>********************************** > >>Madrid 2003 Global IPv6 Summit > >>Presentations and videos on line at: > >>http://www.ipv6-es.com > >> > >>This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents of = this information, including attached files, is prohibited. > >> > >> > >> > > > > > > > > > --=20 > Yu-Shun Wang > USC Information Sciences Institute > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents of = this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Sep 3 05:12:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09320 for ; Fri, 3 Sep 2004 05:12:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C3A6i-000FwL-U0 for v6ops-data@psg.com; Fri, 03 Sep 2004 09:11:44 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C38wc-00042m-AX for v6ops@ops.ietf.org; Fri, 03 Sep 2004 07:57:15 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i837v5Li100818; Fri, 3 Sep 2004 07:57:05 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i837v4xH111298; Fri, 3 Sep 2004 09:57:04 +0200 Received: from zurich.ibm.com (sig-9-146-220-118.de.ibm.com [9.146.220.118]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA70108; Fri, 3 Sep 2004 09:57:03 +0200 Message-ID: <413823CE.40907@zurich.ibm.com> Date: Fri, 03 Sep 2004 09:57:02 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Ciprian Popoviciu CC: IPv6 Operations , patrick Grossetete Subject: Re: I-D ACTION:draft-asadullah-v6ops-bb-deployment-scenarios-00.txt References: <200408191927.PAA27427@ietf.org> <200408191927.PAA27427@ietf.org> <4.3.2.7.2.20040901124020.018d0200@fruitpie.cisco.com> In-Reply-To: <4.3.2.7.2.20040901124020.018d0200@fruitpie.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just one follow up: >> 6) Section 7.5 >> >>> The NAP can stop IPv6 traffic from customer that did not subscribe to >>> the service by using layer two filters based on the IPv6 Ethertype >>> (0X86DD). >> >> >> I think this is irrelevant - it isn't related to a security threat. It's >> also getting into business model territory, which we try to >> avoid in the IETF. > > > @@@ > In a bridged network, wouldn't this be useful as a means for an access provider to > keep its network IPv6 free if it so decides? > @@@ Well yes, but equally if it wants to keep its network free of Novell IPX or Appletalk over Ethernet or any other Ethertype. I really don't see why the IETF should advise providers how to *block* IPv6 specifically. This is a document about how to support IPv6. Maybe you should turn it round: If any layer two filters for Ethertypes are in place, the NAP must permit the IPv6 Ethertype (0X86DD). Brian Ciprian Popoviciu wrote: > > Brian, > > Thank you for your comments and suggestions. Please find in line our > answers, clarifications and questions. We are looking forward to your > response and suggestions. > > Regards, > Chip > > At 05:10 PM 8/26/2004 +0200, Brian E Carpenter wrote: > >> Just a few quick comments on this very long document, which I >> think fills a need (though whether it should be an RFC, or >> expanded into a book, I'm not quite sure). >> >> 1) I think I disagree with one comment Pekka made, about the >> same material being repeated in several sections. I think each of the >> major sections should be complete in itself, to avoid complex cross- >> references. >> >> 2) Here's a comment that I think applies to all four scenarios described. >> The case of subscribers that get more than a /64, actually a /48 if >> RFC 3177 is followed, is not described, unless I missed it. This may only >> apply to a minority of subscribers initially, but it must certainly >> be covered. > > > @@@ > We touched on this subject partially when mentioning the use of DHCP-PD > used to assign /48 to customer premises routers. We are planning to > add more information on this topic so this comment will be integrated > in the next iteration. > @@@ > > >> 3) Just an observation: the document implies in all scenarios that GWR >> vendors will update their products to be fully dual stacked. I can only >> agree that is highly desirable, but you are asking for quite a lot. > > > @@@ > This is true but our intent was to look forward to large scale deployments > where IPv6 is more then a service. We argued that the user can simply get > connectivity through dual stack PCs that talk to the SP edge access > equipment > however, on the long run the users and providers will drive the CPE > manufacturers > to get the GWR ready for dual stack use. > @@@ > > >> 4) Section 5.2.2.1.3 >> >>> 5.2.2.1.3 Data Forwarding >>> >>> All IPv6 traffic will be sent to/from the ER and the host device. >>> In order to transport IPv6 packets over the cable operator's >>> IPv4 network, the host and the ER will need to use tunneling >>> mechanisms such as 6to4 tunneling [RFC 3056]. >>> >>> The host will use its global IPv4 address to source the tunnel to >>> the ER. >> >> >> So, as Pekka also pointed out I think, you are assuming global IPv4 >> addresses at this level. What about countries that are already running >> multiple levels of NAT in order to reach local ISPs? 6to4 is broken in >> that case. Also, you don't explain how the 6to4 relay is discovered - >> do you assume the anycast trick is used (RFC 3068)? And incidentally it >> means that all such hosts will have 6to4 prefixes, so baroque routing >> is likely. 6to4 was designed to *bypass* local ISPs without IPv6 support, >> not to *help* them. > > > @@@ > Our intent was to describe non-tunnel based deployments but rather > deployments similar > to the IPv4 ones. The cable access case study is special because of the > current > state of DOCSIS. This is the reason why tunnels were used here. That being > said, based on the comments we received, it is clear that we need to > expand a bit > more on the topic and provide some clarifications. We will make some > additions and > keep in mind the point raised by this comment. > @@@ > > >> 5) Section 5.2.2.2 >> >>> The cable operator can provide IPv6 services to its customers, >>> in this scenario, by adding a GWR behind the CM. Since the GWR >>> will facilitate all IPv6 traffic to/from the host and the ER, the >>> cable network including the CM and CMTS do not need to support >>> IPv6 and can remain IPv4 devices. >> >> >> But this also has to work when the subscriber goes to the local >> electronics store and buys $99 Wireless Access Gateway, without the >> cable operator lifting a finger. Incidentally, in this case, if >> you use 6to4, the GWR will have to be a full RFC 3056 6to4 router, >> but the hosts behind the GWR don't need to know anything about 6to4. > > > @@@ > True, this falls a bit in the topic of who owns the GWR. Yes, having the > GWR do > the 6to4 tunneling is one of the ways to deal with having a single globally > routable IPv4 address that might be used with NAT for existent v4 > connectivity. > We will elaborate on the topic since it was brought up in other feedback > we received. > @@@ > >> 6) Section 7.5 >> >>> The NAP can stop IPv6 traffic from customer that did not subscribe >>> to the service by using layer two filters based on the IPv6 >>> Ethertype (0X86DD). >> >> >> I think this is irrelevant - it isn't related to a security threat. It's >> also getting into business model territory, which we try to >> avoid in the IETF. > > > @@@ > In a bridged network, wouldn't this be useful as a means for an access > provider to > keep its network IPv6 free if it so decides? > @@@ > > >> 7) Section 10, References >> >> You mention RFC 3056 in the text, but it isn't listed. Also, as noted >> above, >> do you also need a reference to RFC 3068? > > > @@@ > Noted, we will make the necessary corrections. > @@@ > >> Brian >> >> Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : ISP IPv6 Deployment Scenarios in Broadband >>> Access Networks >>> Author(s) : S. Asadullah, et al. >>> Filename : >>> draft-asadullah-v6ops-bb-deployment-scenarios-00.txt >>> Pages : 0 >>> Date : 2004-8-18 >>> >>> This document provides detailed description of IPv6 deployment and >>> integration methods and scenarios in today's Service Provider (SP) >>> Broadband (BB) networks in coexistance with deployed IPv4 services. >>> Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB >>> technologies that are currently deployed, and discussed in this >>> draft. In this document we will discuss main components of IPv6 >>> BB networks and their differences from IPv4 BB networks and how >>> IPv6 is deployed and integrated in each of these BB technologies. >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-00.txt >>> > > > From owner-v6ops@ops.ietf.org Fri Sep 3 05:16:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09587 for ; Fri, 3 Sep 2004 05:15:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C3AAU-000GXU-AH for v6ops-data@psg.com; Fri, 03 Sep 2004 09:15:38 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C3AAF-000GWA-Qc for v6ops@ops.ietf.org; Fri, 03 Sep 2004 09:15:24 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3G00JUAKDMUG@mailout1.samsung.com> for v6ops@ops.ietf.org; Fri, 03 Sep 2004 18:15:23 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3G00MAVK935K@mailout1.samsung.com> for v6ops@ops.ietf.org; Fri, 03 Sep 2004 18:12:39 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3G0044GK90RT@mmp2.samsung.com> for v6ops@ops.ietf.org; Fri, 03 Sep 2004 18:12:39 +0900 (KST) Date: Fri, 03 Sep 2004 14:42:22 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: REVIEW NEEDED: zeroconf requirements document To: juha.wiljakka@nokia.com Cc: Pekka Savola , V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <010a01c49196$1fe06ca0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_jjx/G9u3aT21MBsfTyOG2A)" X-Priority: 3 X-MSMail-priority: Normal References: <4255703385E781428653E1DEE230980D156386@esebe054.ntc.nokia.com> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_jjx/G9u3aT21MBsfTyOG2A) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi Juha, If that is the case, then shouldnt the document name & introduction mention that this document is intended to satisfy the provide zeroconf tunneling goals for transition in 3GPP? IMHO, i guess the need of zeroconf tunnelling is also there in other scenarios and not only in 3GPP. If the document is made in such a way that it addresses zeroconf tunneling goals that can be used in more scenarios it will serve better. Any opinions? Regards Radhakrishnan IPng Team Samsung India Software Operations Bangalore India. ----- Original Message ----- From: To: Sent: Friday, September 03, 2004 2:21 PM Subject: RE: REVIEW NEEDED: zeroconf requirements document Hi, Radhakrishnan! It is because 3GPP Analysis www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt (see sections 3.1 and 6) has found a need for a simple tunneling mechanism. Commission has been given by the ADs to write down a minimal set of requirements required for 3GPP environment automatic tunneling. This was discussed in IETF#60 v6ops meeting. However, this document *may* be applicable for other environments too. BR, -Juha W.- -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Radhakrishnan Suryanarayanan Sent: 03 September, 2004 11:33 To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: zeroconf requirements document Hi Jordi, Why is there a special emphasis on 3GPP in this document? Regards Radhakrishnan ----- Original Message ----- From: "JORDI PALET MARTINEZ" To: Sent: Friday, September 03, 2004 3:45 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document Hi Yushun, Sorry, yes you're right it will make no difference, something very weird happened. Now is solved. http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-01.txt (at least is working for me, both IPv4 and IPv6). But also it has already been published "officially": http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-01.txt Regards, Jordi ----- Original Message ----- From: "Yu-Shun Wang" To: "Karen E. Nielsen (AH/TED)" Cc: ; "JORDI PALET MARTINEZ" Sent: Friday, September 03, 2004 7:49 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document > Karen E. Nielsen (AH/TED) wrote: > > All, > > > > Please use the non-direct link > > http://www.v6ops.euro6ix.net/zerotunnel.php# > > to retrieve the document (draft-nielsen-v6ops-zeroconf-goals-01.txt). > > Hi, Karen, > > That's how I got it. The -00 is fine, but could you check > the -01 file again? > > Thanks, > > yushun > > > I apologize for the inconvenience. > > > > Karen > > > > > >>-----Original Message----- > >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>Behalf Of Yu-Shun Wang > >>Sent: Thursday, September 02, 2004 8:49 PM > >>To: JORDI PALET MARTINEZ > >>Cc: v6ops@ops.ietf.org > >>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >> > >> > >>JORDI PALET MARTINEZ wrote: > >> > >>>Hi all, > >>> > >>>There is also a direct link as > >> > >>http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf > >>-goals-01.txt. > >> > >>Hi, > >> > >>Is it just me or are there non-ASCII characters in the doc file? > >> > >>Thanks, > >> > >>yushun > >> > >> > >>>Regards, > >>>Jordi > >>> > >>>----- Original Message ----- > >>>From: "Karen E. Nielsen (AH/TED)" > >>>To: "'Pekka Savola'" ; > >>>Sent: Friday, September 03, 2004 12:56 AM > >>>Subject: RE: REVIEW NEEDED: zeroconf requirements document > >>> > >>> > >>> > >>> > >>>>Dear All, > >>>> > >>>>The promised revised version, > >>>>draft-nielsen-v6ops-zeroconf-goals-01.txt, > >>>>can be found on the following link: > >>>> > >>>>http://www.v6ops.euro6ix.net/zerotunnel.php# > >>>> > >>>>On behalf of the authors I would like to echo Pekka's > >>>>request for a review of this work. > >>>> > >>>>Feedback are requested on the general scope > >>>>of the documents as well as on the particular set of > >>>>individual goals put forward. > >>>> > >>>>Please scrutinize. > >>>> > >>>>BR, Karen > >>>> > >>>>The drafts has been submitted to the IDs, > >>>>but it will probably take a while for it to appear. > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>>>>Behalf Of Pekka Savola > >>>>>Sent: Wednesday, September 01, 2004 12:29 PM > >>>>>To: v6ops@ops.ietf.org > >>>>>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >>>>> > >>>>> > >>>>>(co-chair hat on) > >>>>> > >>>>>The document editor just said that a revised version, > >> > >>addressing the > >> > >>>>>input received so far, could be available for tomorrow. > >>>>> > >>>>>So, please hold off the review until the new revision has been made > >>>>>available (-01 version). Let's shift the review DL by one > >> > >>day, to 7th > >> > >>>>>September. > >>>>> > >>>>>Thanks to the surprisingly active document editor and authors! :-) > >>>>> > >>>>>(hat off) > >>>>> > >>>>>On Wed, 1 Sep 2004, Pekka Savola wrote: > >>>>> > >>>>> > >>>>>>(co-chair hat on) > >>>>>> > >>>>>>If you recall from the IETF60 meeting, we set out a couple of > >>>>>>milestonoes and deadlines to make progress well before the next > >>>>>>meeting -- and now the planning and scheduling for IETF61 > >>>>> > >>>>>has already > >>>>> > >>>>> > >>>>>>started... > >>>>>> > >>>>>>We need to get more input especially on: > >>>>>> > >>>>>> > >>>> > >>>>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zero > > > > conf-goals-00.txt > > > >>>>Please read it and send feedback on the list. Please do this as soon > >>>>as possible but on 6th September at the latest. > >>>> > >>>>In particular, opinions on whether the document should include the > >>>>applicability in the ISP networks (e.g., when the access network > >>>>cannot be upgraded [which seems to have similar requirements as 3GPP]) > >>>>would be highly appreciated. > >>>> > >>>>Thanks! > >>>> > >>>>(hat off) > >>>> > >>>> > >>> > >>>-- > >>>Pekka Savola "You each name yourselves king, yet the > >>>Netcore Oy kingdom bleeds." > >>>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > >>> > > > > > >>********************************** > >>Madrid 2003 Global IPv6 Summit > >>Presentations and videos on line at: > >>http://www.ipv6-es.com > >> > >>This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > >> > >> > >> > > > > > > > > > -- > Yu-Shun Wang > USC Information Sciences Institute > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. --Boundary_(ID_jjx/G9u3aT21MBsfTyOG2A) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi Juha,
   If that is the case, then  shouldnt the document name & introduction mention that
this document is intended to satisfy the provide zeroconf tunneling goals for transition in 3GPP?
 
 IMHO, i guess the need of zeroconf tunnelling is also there in other scenarios and not only in 3GPP.
If the document is made in such a way that it addresses zeroconf tunneling goals that can be used in more scenarios it will serve better.
 
Any opinions?
 
Regards
Radhakrishnan
 
IPng Team
Samsung India Software Operations
Bangalore
India.
----- Original Message -----
Sent: Friday, September 03, 2004 2:21 PM
Subject: RE: REVIEW NEEDED: zeroconf requirements document

Hi, Radhakrishnan!

It is because 3GPP Analysis
www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt
 (see sections 3.1 and 6)

has found a need for a simple tunneling mechanism. Commission has been given by the ADs to write down a minimal set of requirements required for 3GPP environment automatic tunneling. This was discussed in IETF#60 v6ops meeting.

However, this document *may* be applicable for other environments too.

BR,
-Juha W.-

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
Behalf Of ext Radhakrishnan Suryanarayanan
Sent: 03 September, 2004 11:33
To: JORDI PALET MARTINEZ
Cc: v6ops@ops.ietf.org
Subject: Re: REVIEW NEEDED: zeroconf requirements document


Hi Jordi,
    Why is there a special emphasis on 3GPP in this document?

Regards
Radhakrishnan

----- Original Message -----
From: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
To: <v6ops@ops.ietf.org>
Sent: Friday, September 03, 2004 3:45 AM
Subject: Re: REVIEW NEEDED: zeroconf requirements document


Hi Yushun,

Sorry, yes you're right it will make no difference, something very weird
happened. Now is solved.

http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-01.txt
(at least is working for me, both IPv4 and IPv6).

But also it has already been published "officially":

http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-01.txt

Regards,
Jordi


----- Original Message -----
From: "Yu-Shun Wang" <yushunwa@ISI.EDU>
To: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
Cc: <v6ops@ops.ietf.org>; "JORDI PALET MARTINEZ"
<jordi.palet@consulintel.es>
Sent: Friday, September 03, 2004 7:49 AM
Subject: Re: REVIEW NEEDED: zeroconf requirements document


> Karen E. Nielsen (AH/TED) wrote:
> > All,
> >
> > Please use the non-direct link
> > http://www.v6ops.euro6ix.net/zerotunnel.php#
> > to retrieve the document (draft-nielsen-v6ops-zeroconf-goals-01.txt).
>
> Hi, Karen,
>
> That's how I got it. The -00 is fine, but could you check
> the -01 file again?
>
> Thanks,
>
> yushun
>
> > I apologize for the inconvenience.
> >
> > Karen
> >
> >
> >>-----Original Message-----
> >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> >>Behalf Of Yu-Shun Wang
> >>Sent: Thursday, September 02, 2004 8:49 PM
> >>To: JORDI PALET MARTINEZ
> >>Cc: v6ops@ops.ietf.org
> >>Subject: Re: REVIEW NEEDED: zeroconf requirements document
> >>
> >>
> >>JORDI PALET MARTINEZ wrote:
> >>
> >>>Hi all,
> >>>
> >>>There is also a direct link as
> >>
> >>http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf
> >>-goals-01.txt.
> >>
> >>Hi,
> >>
> >>Is it just me or are there non-ASCII characters in the doc file?
> >>
> >>Thanks,
> >>
> >>yushun
> >>
> >>
> >>>Regards,
> >>>Jordi
> >>>
> >>>----- Original Message -----
> >>>From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
> >>>To: "'Pekka Savola'" <pekkas@netcore.fi>; <v6ops@ops.ietf.org>
> >>>Sent: Friday, September 03, 2004 12:56 AM
> >>>Subject: RE: REVIEW NEEDED: zeroconf requirements document
> >>>
> >>>
> >>>
> >>>
> >>>>Dear All,
> >>>>
> >>>>The promised revised version,
> >>>>draft-nielsen-v6ops-zeroconf-goals-01.txt,
> >>>>can be found on the following link:
> >>>>
> >>>>http://www.v6ops.euro6ix.net/zerotunnel.php#
> >>>>
> >>>>On behalf of the authors I would like to echo Pekka's
> >>>>request for a review of this work.
> >>>>
> >>>>Feedback are requested on the general scope
> >>>>of the documents as well as on the particular set of
> >>>>individual goals put forward.
> >>>>
> >>>>Please scrutinize.
> >>>>
> >>>>BR, Karen
> >>>>
> >>>>The drafts has been submitted to the IDs,
> >>>>but it will probably take a while for it to appear.
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> >>>>>Behalf Of Pekka Savola
> >>>>>Sent: Wednesday, September 01, 2004 12:29 PM
> >>>>>To: v6ops@ops.ietf.org
> >>>>>Subject: Re: REVIEW NEEDED: zeroconf requirements document
> >>>>>
> >>>>>
> >>>>>(co-chair hat on)
> >>>>>
> >>>>>The document editor just said that a revised version,
> >>
> >>addressing the
> >>
> >>>>>input received so far, could be available for tomorrow.
> >>>>>
> >>>>>So, please hold off the review until the new revision has been made
> >>>>>available (-01 version).  Let's shift the review DL by one
> >>
> >>day, to 7th
> >>
> >>>>>September.
> >>>>>
> >>>>>Thanks to the surprisingly active document editor and authors! :-)
> >>>>>
> >>>>>(hat off)
> >>>>>
> >>>>>On Wed, 1 Sep 2004, Pekka Savola wrote:
> >>>>>
> >>>>>
> >>>>>>(co-chair hat on)
> >>>>>>
> >>>>>>If you recall from the IETF60 meeting, we set out a couple of
> >>>>>>milestonoes and deadlines to make progress well before the next
> >>>>>>meeting -- and now the planning and scheduling for IETF61
> >>>>>
> >>>>>has already
> >>>>>
> >>>>>
> >>>>>>started...
> >>>>>>
> >>>>>>We need to get more input especially on:
> >>>>>>
> >>>>>>
> >>>>
> >>>>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zero
> >
> > conf-goals-00.txt
> >
> >>>>Please read it and send feedback on the list.  Please do this as soon
> >>>>as possible but on 6th September at the latest.
> >>>>
> >>>>In particular, opinions on whether the document should include the
> >>>>applicability in the ISP networks (e.g., when the access network
> >>>>cannot be upgraded [which seems to have similar requirements as 3GPP])
> >>>>would be highly appreciated.
> >>>>
> >>>>Thanks!
> >>>>
> >>>>(hat off)
> >>>>
> >>>>
> >>>
> >>>--
> >>>Pekka Savola                 "You each name yourselves king, yet the
> >>>Netcore Oy                    kingdom bleeds."
> >>>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >>>
> >
> >
> >>**********************************
> >>Madrid 2003 Global IPv6 Summit
> >>Presentations and videos on line at:
> >>http://www.ipv6-es.com
> >>
> >>This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> Yu-Shun Wang <yushunwa@isi.edu>
> USC Information Sciences Institute
>


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) named above. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, including attached files, is prohibited.






 --Boundary_(ID_jjx/G9u3aT21MBsfTyOG2A)-- From owner-v6ops@ops.ietf.org Fri Sep 3 05:39:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11084 for ; Fri, 3 Sep 2004 05:39:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C3AWY-000Jns-NR for v6ops-data@psg.com; Fri, 03 Sep 2004 09:38:26 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C3AWN-000Jme-IF for v6ops@ops.ietf.org; Fri, 03 Sep 2004 09:38:15 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i839c6127701; Fri, 3 Sep 2004 12:38:06 +0300 (EET DST) X-Scanned: Fri, 3 Sep 2004 12:35:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i839Z2Uf024443; Fri, 3 Sep 2004 12:35:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00Fc2t9t; Fri, 03 Sep 2004 12:35:00 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i839YwY00233; Fri, 3 Sep 2004 12:34:58 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 12:34:57 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Sep 2004 12:34:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: REVIEW NEEDED: zeroconf requirements document Date: Fri, 3 Sep 2004 12:34:57 +0300 Message-ID: <4255703385E781428653E1DEE230980D156387@esebe054.ntc.nokia.com> Thread-Topic: REVIEW NEEDED: zeroconf requirements document Thread-Index: AcSRlsuyrdOsCx0HQK6LwlJdu2RNsQAARXLQ From: To: Cc: , X-OriginalArrivalTime: 03 Sep 2004 09:34:57.0101 (UTC) FILETIME=[46705FD0:01C49199] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi! Pls see our presentation in San Diego: http://www.6bone.net/v6ops/minutes/IETF-60-SanDiego/12_zeroconfig-reqs.pd= f "Starting Point of actual work * Minimal set of goals required for the 3GPP environment automatic tunneling scenario ....may widen to other environment scenarios (not explicit assumption nor prerequisite) * More advanced and feature rich tunneling is envisaged provided in form of assisted-tunneling, " Timing is critical in this work, so we have written our first two drafts = in a short time - mainly focusing on the (important) 3GPP environment. One point is that can the work done in assisted tunneling satisfy = tunneling needs in other environments? http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-r= equirements-00.txt=20 If yes, then zeroconf document could more tightly be scoped to 3GPP... Of course, zeroconf document team is open for comments from the people = in the v6ops wg. Cheers, -Juha- -----Original Message----- From: ext Radhakrishnan Suryanarayanan [mailto:rkrishnan.s@samsung.com] Sent: 03 September, 2004 12:12 To: Wiljakka Juha (Nokia-M/Tampere) Cc: Pekka Savola; V6OPS WG Subject: Re: REVIEW NEEDED: zeroconf requirements document Hi Juha, If that is the case, then shouldnt the document name & introduction = mention that this document is intended to satisfy the provide zeroconf tunneling = goals for transition in 3GPP? IMHO, i guess the need of zeroconf tunnelling is also there in other = scenarios and not only in 3GPP. If the document is made in such a way that it addresses zeroconf = tunneling goals that can be used in more scenarios it will serve better. Any opinions? Regards Radhakrishnan IPng Team Samsung India Software Operations Bangalore India. ----- Original Message -----=20 From: To: Sent: Friday, September 03, 2004 2:21 PM Subject: RE: REVIEW NEEDED: zeroconf requirements document Hi, Radhakrishnan! It is because 3GPP Analysis www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-10.txt (see sections 3.1 and 6) has found a need for a simple tunneling mechanism. Commission has been = given by the ADs to write down a minimal set of requirements required = for 3GPP environment automatic tunneling. This was discussed in IETF#60 = v6ops meeting. However, this document *may* be applicable for other environments too. BR, -Juha W.- -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of ext Radhakrishnan Suryanarayanan Sent: 03 September, 2004 11:33 To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: zeroconf requirements document Hi Jordi, Why is there a special emphasis on 3GPP in this document? Regards Radhakrishnan ----- Original Message -----=20 From: "JORDI PALET MARTINEZ" To: Sent: Friday, September 03, 2004 3:45 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document Hi Yushun, Sorry, yes you're right it will make no difference, something very weird happened. Now is solved. http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-01.t= xt (at least is working for me, both IPv4 and IPv6). But also it has already been published "officially": http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-01= .txt Regards, Jordi ----- Original Message -----=20 From: "Yu-Shun Wang" To: "Karen E. Nielsen (AH/TED)" Cc: ; "JORDI PALET MARTINEZ" Sent: Friday, September 03, 2004 7:49 AM Subject: Re: REVIEW NEEDED: zeroconf requirements document > Karen E. Nielsen (AH/TED) wrote: > > All, > > > > Please use the non-direct link > > http://www.v6ops.euro6ix.net/zerotunnel.php# > > to retrieve the document = (draft-nielsen-v6ops-zeroconf-goals-01.txt). > > Hi, Karen, > > That's how I got it. The -00 is fine, but could you check > the -01 file again? > > Thanks, > > yushun > > > I apologize for the inconvenience. > > > > Karen > > > > > >>-----Original Message----- > >>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > >>Behalf Of Yu-Shun Wang > >>Sent: Thursday, September 02, 2004 8:49 PM > >>To: JORDI PALET MARTINEZ > >>Cc: v6ops@ops.ietf.org > >>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >> > >> > >>JORDI PALET MARTINEZ wrote: > >> > >>>Hi all, > >>> > >>>There is also a direct link as > >> > >>http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf > >>-goals-01.txt. > >> > >>Hi, > >> > >>Is it just me or are there non-ASCII characters in the doc file? > >> > >>Thanks, > >> > >>yushun > >> > >> > >>>Regards, > >>>Jordi > >>> > >>>----- Original Message -----=20 > >>>From: "Karen E. Nielsen (AH/TED)" > >>>To: "'Pekka Savola'" ; > >>>Sent: Friday, September 03, 2004 12:56 AM > >>>Subject: RE: REVIEW NEEDED: zeroconf requirements document > >>> > >>> > >>> > >>> > >>>>Dear All, > >>>> > >>>>The promised revised version, > >>>>draft-nielsen-v6ops-zeroconf-goals-01.txt, > >>>>can be found on the following link: > >>>> > >>>>http://www.v6ops.euro6ix.net/zerotunnel.php# > >>>> > >>>>On behalf of the authors I would like to echo Pekka's > >>>>request for a review of this work. > >>>> > >>>>Feedback are requested on the general scope > >>>>of the documents as well as on the particular set of > >>>>individual goals put forward. > >>>> > >>>>Please scrutinize. > >>>> > >>>>BR, Karen > >>>> > >>>>The drafts has been submitted to the IDs, > >>>>but it will probably take a while for it to appear. > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: owner-v6ops@ops.ietf.org = [mailto:owner-v6ops@ops.ietf.org]On > >>>>>Behalf Of Pekka Savola > >>>>>Sent: Wednesday, September 01, 2004 12:29 PM > >>>>>To: v6ops@ops.ietf.org > >>>>>Subject: Re: REVIEW NEEDED: zeroconf requirements document > >>>>> > >>>>> > >>>>>(co-chair hat on) > >>>>> > >>>>>The document editor just said that a revised version, > >> > >>addressing the > >> > >>>>>input received so far, could be available for tomorrow. > >>>>> > >>>>>So, please hold off the review until the new revision has been = made > >>>>>available (-01 version). Let's shift the review DL by one > >> > >>day, to 7th > >> > >>>>>September. > >>>>> > >>>>>Thanks to the surprisingly active document editor and authors! = :-) > >>>>> > >>>>>(hat off) > >>>>> > >>>>>On Wed, 1 Sep 2004, Pekka Savola wrote: > >>>>> > >>>>> > >>>>>>(co-chair hat on) > >>>>>> > >>>>>>If you recall from the IETF60 meeting, we set out a couple of > >>>>>>milestonoes and deadlines to make progress well before the next > >>>>>>meeting -- and now the planning and scheduling for IETF61 > >>>>> > >>>>>has already > >>>>> > >>>>> > >>>>>>started... > >>>>>> > >>>>>>We need to get more input especially on: > >>>>>> > >>>>>> > >>>> > >>>>http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zero > > > > conf-goals-00.txt > > > >>>>Please read it and send feedback on the list. Please do this as = soon > >>>>as possible but on 6th September at the latest. > >>>> > >>>>In particular, opinions on whether the document should include the > >>>>applicability in the ISP networks (e.g., when the access network > >>>>cannot be upgraded [which seems to have similar requirements as = 3GPP]) > >>>>would be highly appreciated. > >>>> > >>>>Thanks! > >>>> > >>>>(hat off) > >>>> > >>>> > >>> > >>>--=20 > >>>Pekka Savola "You each name yourselves king, yet = the > >>>Netcore Oy kingdom bleeds." > >>>Systems. Networks. Security. -- George R.R. Martin: A Clash of = Kings > >>> > > > > > >>********************************** > >>Madrid 2003 Global IPv6 Summit > >>Presentations and videos on line at: > >>http://www.ipv6-es.com > >> > >>This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents of = this information, including attached files, is prohibited. > >> > >> > >> > > > > > > > > > --=20 > Yu-Shun Wang > USC Information Sciences Institute > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents of = this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Sep 5 22:29:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08980 for ; Sun, 5 Sep 2004 22:29:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C49Bo-0009BV-DX for v6ops-data@psg.com; Mon, 06 Sep 2004 02:25:04 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C49BM-00095t-Gi for v6ops@ops.ietf.org; Mon, 06 Sep 2004 02:24:37 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000402513.msg for ; Mon, 06 Sep 2004 04:28:31 +0200 Message-ID: <09a401c493b8$a9484d90$3220dfa9@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: IPv6 Tunnel End-point Automatic Discovery Mechanism Date: Mon, 6 Sep 2004 04:23:57 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 06 Sep 2004 04:28:31 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 06 Sep 2004 04:28:34 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, We have submitted a new document. It can be already read at: http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-solution-tun-auto-disc-00.txt Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Sep 6 19:12:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09713 for ; Mon, 6 Sep 2004 19:12:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4SbP-000DLy-D4 for v6ops-data@psg.com; Mon, 06 Sep 2004 23:08:47 +0000 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4SbE-000DKm-AZ for v6ops@ops.ietf.org; Mon, 06 Sep 2004 23:08:36 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 574E2178A4; Tue, 7 Sep 2004 01:08:35 +0200 (CEST) Date: Tue, 7 Sep 2004 01:08:35 +0200 From: Daniel Roesen To: ipv6-wg@ripe.net, v6ops@ops.ietf.org Cc: nstld@verisign-grs.com, noc@icann.org, bind@arin.net, hostmaster@icann.org, hostmaster@ep.net Subject: DNS Weather Report 2004-09-07 Message-ID: <20040906230835.GA692@srv01.cluenet.de> Mail-Followup-To: ipv6-wg@ripe.net, v6ops@ops.ietf.org, nstld@verisign-grs.com, noc@icann.org, bind@arin.net, hostmaster@icann.org, hostmaster@ep.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-09-07 Zones analyzed and their SOA contacts: - . - arpa. nstld@verisign-grs.com - int. noc@icann.org - in-addr.arpa bind@arin.net - ip6.arpa. hostmaster@icann.org - ip6.int. hostmaster@ep.net Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily! Some people have approached me wether it would be possible to receive personal copies of the report. Please let me know wether you are interested in such a service yourself. If there is enough interest, I will set up a distro list for that. Executive summary: * the IP6.ARPA problems regarding delegation NS RRset got fixed! * ns.isi.edu is _still_ out of sync for the INT zone. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004090400, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== fine! The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel From owner-v6ops@ops.ietf.org Tue Sep 7 02:23:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21397 for ; Tue, 7 Sep 2004 02:23:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4ZJx-000B1n-Ez for v6ops-data@psg.com; Tue, 07 Sep 2004 06:19:13 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4ZJm-000B0a-97 for v6ops@ops.ietf.org; Tue, 07 Sep 2004 06:19:02 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i876J0Li081766 for ; Tue, 7 Sep 2004 06:19:00 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i876J06A106664 for ; Tue, 7 Sep 2004 08:19:00 +0200 Received: from zurich.ibm.com (sig-9-145-230-227.de.ibm.com [9.145.230.227]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA38302 for ; Tue, 7 Sep 2004 08:18:59 +0200 Message-ID: <413D52D0.2010106@zurich.ibm.com> Date: Tue, 07 Sep 2004 08:18:56 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 Operations Subject: draft-palet-v6ops-solution-tun-auto-disc-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jordi and Miguel, One quick question: did you consider SLP as another solution? I think it at least deserves a paragraph saying why you don't recommend it. Brian From owner-v6ops@ops.ietf.org Tue Sep 7 02:52:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23116 for ; Tue, 7 Sep 2004 02:52:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4ZoQ-000EQj-2R for v6ops-data@psg.com; Tue, 07 Sep 2004 06:50:42 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4ZoE-000EMl-Kx for v6ops@ops.ietf.org; Tue, 07 Sep 2004 06:50:31 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000405992.msg for ; Tue, 07 Sep 2004 08:54:29 +0200 Message-ID: <135201c494a6$e6d04f70$3220dfa9@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <413D52D0.2010106@zurich.ibm.com> Subject: Re: draft-palet-v6ops-solution-tun-auto-disc-00.txt Date: Tue, 7 Sep 2004 08:50:02 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Tue, 07 Sep 2004 08:54:29 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.135 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Tue, 07 Sep 2004 08:54:31 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Brian, In the document v6ops-tun-auto-disc, which is the analysis we have included SLP. This document is being updated right now and will be submitted this week, hopefully. In the solution one, we wanted to have a simple solution, which from our point of view is why we have chosen (SRV + anycast) as doesn't require any new infrastructure changes, including installing any new software, etc. So yes, we didn't believe SLP is an appropriate solution. This is much better explained in the v6ops-tun-auto-disc that you will see soon, and we will be very happy to see your inputs in the case you believe we are wrong with that analysis. Regards, Jordi ---- Original Message ---- From: "Brian E Carpenter" To: "IPv6 Operations" Sent: Tuesday, September 07, 2004 8:18 AM Subject: draft-palet-v6ops-solution-tun-auto-disc-00.txt > Jordi and Miguel, >=20 > One quick question: did you consider SLP as another solution? > I think it at least deserves a paragraph saying why you don't > recommend it. >=20 > Brian ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Sep 7 03:56:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27569 for ; Tue, 7 Sep 2004 03:56:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4ap2-000Lua-Gq for v6ops-data@psg.com; Tue, 07 Sep 2004 07:55:24 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4aoq-000Lt0-WE for v6ops@ops.ietf.org; Tue, 07 Sep 2004 07:55:13 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3N00HFFVBYXF@mailout3.samsung.com> for v6ops@ops.ietf.org; Tue, 07 Sep 2004 16:55:10 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3N00MT5V9Y0O@mailout3.samsung.com> for v6ops@ops.ietf.org; Tue, 07 Sep 2004 16:53:59 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3N00E0DV9X5F@mmp2.samsung.com> for v6ops@ops.ietf.org; Tue, 07 Sep 2004 16:53:58 +0900 (KST) Date: Tue, 07 Sep 2004 16:55:12 +0900 From: "S. Daniel Park" Subject: RE: IPv6 Tunnel End-point Automatic Discovery Mechanism In-reply-to: <09a401c493b8$a9484d90$3220dfa9@consulintel.es> To: JORDI PALET MARTINEZ , v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Jordi, thanks your effort on this work. Basically, you have to use a new boilerplate for this draft. In this draft, several abbreviations (i.e., TEP, TS, TEB...) are shown without any terminology description, so I recommend you to simply address them if possible. My major comment is as below; In Abstract; >This memo proposes a solution for discovering the IPv6 TEP >in a simple an efficient way. Isn't the IPv4 TEP correct ? (if you mean tunnel described in this draft is the IPv6-over-IPv4 tunnel). IPv6-over-IPv4 tunnel where the IPv4 tunnel endpoint address is learned from the solutions proposed in this draft. If you mean IPv6 TEP is only *endpoint* from the IPv6 aspect, you should at lease address this assumption and indicate the difference between TEP and TEP address. For example: TEP address is a destination address of IPv4 encapsulating IPv6 packets where IPv6-over-IPv4 tunnel is the technique of encapsulating IPv6 packets within IPv4 is used to accross IPv4 routing infrastructures. Thanks - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org]On Behalf Of JORDI PALET MARTINEZ > Sent: Monday, September 06, 2004 11:24 AM > To: v6ops@ops.ietf.org > Subject: IPv6 Tunnel End-point Automatic Discovery Mechanism > > > Hi, > > We have submitted a new document. It can be already read at: > > http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-solution > -tun-auto-disc-00.txt > > Regards, > Jordi > > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be > privileged or confidential. The information is intended to be for > the use of the individual(s) named above. If you are not the > intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, > including attached files, is prohibited. > > > > > From owner-v6ops@ops.ietf.org Tue Sep 7 05:37:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04956 for ; Tue, 7 Sep 2004 05:37:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4cMo-0006qP-VY for v6ops-data@psg.com; Tue, 07 Sep 2004 09:34:22 +0000 Received: from [193.6.222.240] (helo=mail.ki.iif.hu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4cMc-0006oV-N4 for v6ops@ops.ietf.org; Tue, 07 Sep 2004 09:34:11 +0000 Received: by mail.ki.iif.hu (Postfix, from userid 1003) id 162745516; Tue, 7 Sep 2004 11:34:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 135B654D9; Tue, 7 Sep 2004 11:34:09 +0200 (CEST) Date: Tue, 7 Sep 2004 11:34:09 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: snap-users@kame.net Cc: v6ops@ops.ietf.org Subject: Re: how to mitigate misbehavior agains AAAA In-Reply-To: Message-ID: <20040907101924.D91350@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 7 Sep 2004, Pekka Savola wrote: > Sorry for not responding earlier.. > > On Wed, 1 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: >>>> One really weird case where AI_ADDRCONFIG would be the only solution >>>> is that the host performing getaddrinfo hasn't configured global IPv6 >>>> addresses and DNS queries for AAAA resource records cause serious >>>> problem like the ones documented in >>>> draft-ietf-dnsop-misbehavior-against-aaaa-01.txt. However, we >>>> basically think we can only solve this by fixing and upgrading the >>>> broken servers, rather than by an introducing additional hack in the >>>> host implementation. >> >>> But from the practical point of view, do you see this happening fast >>> enough to suit the IPv6 deployment? Remember that we have experienced >>> the same issue with ECN: it has been PS for 3 years or so, and even >>> now it hasn't been generally turned on because it causes the users to >>> see breakage. >> >>> So, IMHO it would make sense to think *real* hard whether there are >>> reasonable ways to work around this particular problem >>> (draft-ietf-dnsop-ipv6-issues points out a couple of possibilities, >>> e.g., firing off the queries in parallel or after e.g. 1 sec if there >>> is no response, etc.) >> >>> At least, this issue should not affect the users who don't use IPv6 >>> (IMHO), so a solution like AI_ADDRCONFIG seems to be called for. >> >> If the work around can be a complete solution, even if it's ad-hock, I >> agree that it's worth considering. I also tend to agree that your >> suggestion of the parallel query plus short timeout can be considered >> as this type of work around. > > Yep. > >> My point on AI_ADDRCONFIG was that it cannot be a complete solution to >> the AAAA misbehavior issue since it doesn't help in the case where we >> have IPv6 connectivity. > > It seems like a good solution for the case where you want to deploy > dual-stack -enabled nodes which would not necessarily get IPv6 > connectivity (e.g., nodes, which wouldn't activate 6to4, Teredo, or > the like automatically, but just wait for native IPv6). > > The good side of using something like AI_ADDRCONFIG would be that the > vendors would be less reluctant to enable IPv6 by default if you > wouldn't even try to look up the v6 records (causing potential > problems) *until* you get v6 connectivity. > > Remember, it's of utmost importance to be able to *safely* deploy > *IPv6 capability*, even if that capability would not be used > immediately... > > However, AI_ADDRCONFIG would need to be enabled by default (like with > sysctl -- the RFC is unclear with this when it describes something > like "AI_DEFAULT" but doesn't say more on that -- it's not clear > whether that's assumed to be the default setting) for that to work, > because otherwise all the apps would need to be modified which seems > too late now... Hi Pekka and all, Sorry for cross-posting, but I think this discussion can take place most appropriately on v6ops mailing list. I completely agree with you in ideas e.g. deploying dual stacked hosts as much as possible (by default!). - I would leave AI_ADDRCONFIG as defined RFC3493. - I would insist on proper implementation of Default Address Selection for IPv6 (RFC3484) on all dual-stacked hosts. You could have different types of operation: 1. IPv6 not configured -> IPv6 not preferred: old-fashioned IPv4 only operation 2. IPv6 configured + IPv4 preferred: AI_ADDRCONFIG - says configured, so you get IPv6 address records, but the connection is done via IPv4 even if the remote host have IPv6 address records. End user could experiment with IPv6 locally or remotely if they prefer. - RFC 3484 is very flexible. 3. IPv6 configured + IPv6 preferred: The user has decent IPv6 connectivity. IPv6 connectivity is preferred. I would implement the configuration the following way in the operating system installation process: 1. - Ask for IPv6 configuration of interfaces. 2. - Ask for IPv6 preference to IPv4. I would warn the administrator, that they need good IPv6 connectivity if they prefer IPv6 to IPv4 (Asking ISPs etc....) Unfortunately this does not solve the the problem of misbehaving DNS servers against AAAA query. The other problem is, that you will lose some principle of dual-stack operation: - When you are dual stacked IPv6 preferred over IPv4 to promote IPv6. I think IPv6 community got into a troublesome situation: - IPv6 host implementations are there - they are very good - IPv6 router implementations are there - they are good - There hardly any IPv6 network that support endusers (some exceptions at the academic and research communities). ISPs are very reluctant to implement IPv6....- Some good examples are (WIDE, 6NET, EURO6IX, GEANT and Internet2). - Some end-users are already eager to use IPv6 - see the popularity of different Tunnel-Broker services. But most of them are don't care: they want to use service regardless of underlying protocol (IPv4 or IPv6, or "homing pigeon carrying the packets...") Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 From owner-v6ops@ops.ietf.org Tue Sep 7 06:54:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12290 for ; Tue, 7 Sep 2004 06:54:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4db3-000Gd2-6m for v6ops-data@psg.com; Tue, 07 Sep 2004 10:53:09 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4das-000Gb6-8X for v6ops@ops.ietf.org; Tue, 07 Sep 2004 10:52:58 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i87Aquj22980 for ; Tue, 7 Sep 2004 13:52:56 +0300 (EET DST) X-Scanned: Tue, 7 Sep 2004 13:52:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i87AqfjP001493 for ; Tue, 7 Sep 2004 13:52:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00LQrYBg; Tue, 07 Sep 2004 13:52:40 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i87AqdY07474 for ; Tue, 7 Sep 2004 13:52:39 +0300 (EET DST) Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Sep 2004 13:52:39 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 7 Sep 2004 13:52:39 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Teredo client - native IPv6 client communication Date: Tue, 7 Sep 2004 13:52:33 +0300 Message-ID: Thread-Topic: Teredo client - native IPv6 client communication Thread-Index: AcSUyMgGQbca7UfHRoOzjGYroTkjjw== From: To: X-OriginalArrivalTime: 07 Sep 2004 10:52:39.0282 (UTC) FILETIME=[CAF7BD20:01C494C8] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I'm a bit confused how the case where initial communication is = established between a Teredo client (behind restricted NAT) and a native = IPv6 client, is handled. When the Teredo relay receives the ICMPv6 echo = reply from the native IPv6 client it queues it and send a bubble to the = Teredo client's Teredo server. When Teredo server receives the bubble it = encapsulates it to a new UDP datagram and sets its own IPv4 address and = port as the source.=20 Now, all I could find in the draft was that if a client receives a = packet from its Teredo Server with an origin indication, it should = perform "direct IPv6 connectivity test" (section 5.2.3). How is the = mapping created to the NAT for the ICMPv6 echo reply packet from the = Teredo relay? Should a direct bubble be sent to the Teredo relay instead = of the "direct IPv6 connectivity test"? That's the what I understand the = relay is expecting. Thanks, Markku ------ Markku Ala-Vannesluoma Nokia Tel: +358 50 031 32 14 E-mail: markku.ala-vannesluoma@nokia.com From owner-v6ops@ops.ietf.org Tue Sep 7 07:44:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14561 for ; Tue, 7 Sep 2004 07:44:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4eO0-000Miu-T5 for v6ops-data@psg.com; Tue, 07 Sep 2004 11:43:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4eNY-000Mfc-J3 for v6ops@ops.ietf.org; Tue, 07 Sep 2004 11:43:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i87Bh4m01490; Tue, 7 Sep 2004 14:43:04 +0300 Date: Tue, 7 Sep 2004 14:43:04 +0300 (EEST) From: Pekka Savola To: Ciprian Popoviciu cc: v6ops@ops.ietf.org, Adeel Ahmed , Salman Asadullah , Patrick Grossetete Subject: Re: Draft on ISP broad-band deployment scenarios In-Reply-To: <4.3.2.7.2.20040831213539.018e7e80@fruitpie.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Sorry for the delay in responding.. inline... (I've removed some comments which we seemed to agree or be clear about.) On Wed, 1 Sep 2004, Ciprian Popoviciu wrote: > >On Thu, 19 Aug 2004, Pekka Savola wrote: > > > Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a > > > lot of work in a very short time and produced a really extensive > > > scenarios document discussing the IPv6 deployment scenarios for > > > broadband (DSL, cable, etc.). > > > >A couple of general observations: > > > > 0) is the document aiming to only describe the scenarios, or is the > >goal to also provide analysis where potential gaps have been > >identified, and where e.g., a tunneling mechanism would be needed? If > >the latter, it probably needs to be expanded a bit. > > @@@ > Pekka, to put this document in perspective, here are some elements of our > original intent: > - focus on production type deployments. We did not intend to discuss tunneling > unless it is the only alternative currently available due to limitations of > a given access > technology (cable). OK, though I'm not sure how certain types of tunneling solutions could not be considered "production" (or sufficiently near that) to be useful on a larger scale. The justification for that is that there may be lots of equipment that is not IPv6-capable, and having to wait for it to be replaced to be able to offer (or get) IPv6 connectivity may be a big assumption for deployment. > - present the possible deployment scenarios and identify the major elements > for each one in terms of enabling IPv6 services. > - highlight changes that have to be made in the deployment process and some > issues that the SP has to keep in mind while planning such a deployment. > > As you can see, the document is rather large as it is so we did not consider > going into more detail then we already did. We did want however to underline > topics that should be kept in mind during deployment, even items that should be > further investigated. We believe that this approach is what you mentioned above > but maybe we need to highlight more some aspects of the document. Could you > clarify > your comment above so that we make sure we properly understand the changes you > suggest? We would like to make this work as useful as possible. > @@@ This is partially clarified later in this message, esp. point 1) below. The question I was asking was whether you intended to analyze the applicability of different methods for getting IPv6 connectivity (in case there would be multiple: for example, where you cite 6to4, there could very likely be others as well, possibly even more suitable than that), or just pick one (or none) and describe how that would work. In other words, I was interested whether you were considering "generic" deployment (with as few assumptions as reasonable, about, e.g., equipment at the customer's premises), or "specific" deployment (where you could or could not assume some things, like being able to upgrade a certain box or having public IPv4 addresses). The document would certainly seem to be most useful if it was sufficiently "generic", but a "specific" document is also better than nothing ;-), provided that the assumptions are very clearly spelled out. > > 1) the doc seems to be lacking large-scale v6 enablement > >considerations, w/o customer interaction and manual config. That is, > >at least in section 5, I got the impression that for the customer to > >enable v6 over a tunnel, the customer and the ISP would have to do > >some manual configuration. This seems unscalable and unfeasible. > >Shouldn't we try to have mechanisms where the nodes automatically > >detect if IPv6 is available through a tunnel, and activate it if so? > > @@@ > This is a good point that we should elaborate on. It is also true that > while in some cases simple provisioning is available (use of autoconfig or > DHCP-PD) in others there might not be a solution available today. In such > cases, > based on your comment above, it looks like you would like to see us clearly > identify such limitations and possibly open the door for further work. Is this > correct? Yes -- I don't see it as a problem that a document idenitifies gaps or room for further work. That's good, because at least some folks already have their own view on what's needed, and by writing it down we can discuss and get (hopefully!) agreement on what's needed. Note that there has already been work in progress in some of these areas (see, for example, http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-01.txt). > > 2) the document seems to make some assumptions e.g., when it specifies to > >use 6to4 e.g., for cable. Are all of the networks using public v4 > >addresses? What if the customer has deployed a NAT box so that the public > >address is consumed by that box? Further, I'm not sure whether the > >situation where the customer has deployed some equipment has been considered > >throughout the document. > > @@@ > Again, it is a case very specific to the current state of Cable > access. Do you mean that cable operators are widely offering a public IP address per customer? However, I'd venture to guess there are a significant number of operators which only give private addresses to begin with. > Nevertheless we could probably offer more detail for this > case. For example, one solution would be to have the box that is > doing the NAT for the user also terminate the tunnel. > > This is another point that we need to clarify however, the Gateway > Router (GWR) can be SP owned but also it can be customer owned and > in that case it would reflect a customer deployed equipment like a > box that does NAT for v4. > @@@ Exactly, this cuts both ways: one approach could be to assume that the NAT box (which may be beyond the control of the SP) is upgraded -- this could take quite a long time to achieve. Another approach could be to provide mechanisms which work irrespective of NATs -- there are already a plenty of those, for example Teredo, and some others probably to come (think of "configured tunneling over UDP with keepalives"), in one form or the other. I think what you were assuming that you only need to care about the case of upgrading the NAT box. That may be acceptable with certain assumptions about the deployment (if that's the case, they must be very clearly spelled out), but it may not be sufficient in more general -- so if you agree that one would want to provide v6 access also when there are NATs or other obstacles in the way, one such approach is to specify v6 connectivity mechanissm which work through a NAT. > > 3) there's duplicated text in very many of the sections which applies > >to about all the scenarios, for example: > > > > Depending on the design of the edge portion of the ISP network, some > > Edge Routers might have to run iBGP for IPv6. In this case it is > > expected that two peer sessions are established between the Edge > > Router and a pair of redundant Route Reflectors. > > > >.. instead of duplication, would there be a good logical place to put > >all the "generic considerations" wrt. access networks (e.g., about > >prefix summarization, etc.) into a dedicated section? -- And just > >describe the access-network -specific issues under the access > >network.. that might remove duplicate text and make the document more > >concise. > > > >This might force the reader to think about the generic issue and how they > >map to the specific access network scenario a bit more, but it would > >probably improve the readability and correctness. > > > >The tradeoff of course is that each access network description would no > >longer be readable on its own without reading the rest, but that should > >probably be acceptable ... as it is, there seems to be significant overlap > >with the sections, especially with DSL, Ethernet, and WLAN, but a bit > >otherwise as well. > > > >If that was done, it might be possible to push down from 60 pages to > >20-30 pages, and even increase the amount of unique content in the > >process. > > @@@ > Before writing the document we actually discussed this topic amongst > ourselves. Our thought is that some items might seem similar between > sections but they might not be in all their details. Moreover, we > did want to provide each Access Technology section a certain > completeness and independence in order to make the sections more > readable, without having to send the reader very far through > referencing. Even if we were to compress the repeated subsections we > doubt that the document will shrink to only 30 pages. We received > pro and con arguments on this topic so for now we would like to keep > it in this format as it might even be easier to further flesh out > some sections based on the feedback received. As the document > evolves we can revisit the formatting if it proves advantageous. > @@@ Would there be some kind of middle-path, e.g., a section describing more generic considerations which are actually common to all the access networks (or close enough)? I'm a bit afraid of the scenario where we'd have to include identical text in 5 different sections if we figured out we needed to add some common text :) But if you believe this is sufficient at this point, I can live with it. I've just seen (in the past) a lot of work getting spent in keeping the text in sync, and I wanted to avoid that if possible. > >==> actually, the current recommendation (RFC 3177) is even larger: a /48 > >per home :-). This should probably be mentioned.. > > @@@ > True. We sort of touched on that with our DHCP-PD recommendations. There > are also > SPs that might assign prefixes between /48 and /64 with the intent of charging > for address space. > @@@ Yes, seems inevitable -- but let's just hope they'd still give at least /64 or something like that, instead of /128's. > > 2. IPv4 Cable (HFC) Network, GWR at customer site > > > > In this case the cable network, including the CM and CMTS remain > > IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This > > scenario is also easy to deploy since the cable operator just needs > > to add GWR at the customer's site. > > > >==> is this necessarily this simple? What is the cable operator already has > >deployed v4-only GWR for other purposes? Does it need to be upgraded to > >dual-stack? Or what if the user has added a box of its own, e.g., a > >firewall/NAT/wireless router? I guess it again needs to be upgraded. > > @@@ > These are deployment issues that we could elaborate a bit more on. The > provider usually > is not responsible for the additional equipment added by the customer and > under the > constraints of a service deployment that is limited by the current state of > DOCSIS it is likely that > the provider will have to provide a new device to the subscriber. We will > add a note on this > topic. > @@@ This is one approach, as noted at the start of the message; another is providing tunneling support. Both could be feasible, depending on deployment, but the latter is more generic at least. > >5.2.2.2.4 Routing > > > > > > For 6to4 tunneling,a static 2002::/16 route and a default IPv6 route > > can be manually configured on the GWR with the IPv6 address of the ER > > as the next hop. A similar IPv6 route will need to be configured on > > the ER pointing back to the GWR at customer site. > > > >==> does that require manual configuration at ER for each customer? > >Hopefully not! (AFAICS, there's nothing needed for 6to4, but manual > >tunneling would need it.) > > @@@ > We will discuss provisioning in more detail and hopefully this question > will be answered in > that context. It is worthwhile to note that we don't advocate the use of a > specific tunneling > mechanism for this temporary solution for Cable Networks. We will more > clearly identify > items to be considered when making the selection for the tunnel but the > selection will > be left to the person planning the deployment. > @@@ OK -- Analyzing the different mechanisms is fine. However, if it requires IETF specification, there must be some document that makes the decision what needs to be specified (if not everything). It doesn't need to be in this doc, though. (This was my point zero at the start of the message -- whether this doc was intended to include analysis, and if so, how much of it...) > > If using maunual tunneling, the GWR and ER can use static routing or > > they can also configure RIP-ng. The RIP-ng updates can be transported > > over a manual tunnel, which does not work when using 6to4 tunneling. > > > >==> is there a particular usage case for RIP-ng over cable modem to the GWR? > >I can't see any valid scenario for doing so.... > > @@@ > This is a valid point. We need to provide more context to the statement, > but it is worthwhile > to note that it is a current practice in IPV4 networks where business > customer do run RIPv2 > between the CM/GWR and the CMTS. Those customer routes are redistributed in > the ISP's IGP. > @@@ OK -- I'm just having trouble visualizing any ISP doing so, because that might directly jeopardize their IGP to the customers.. and I'd be interested in hearing why they would be doing something like this (is this some kind of backup routing plan for some SOHO customers or the like or what). > > The CMTS/ER should protect the ISP network and the other subscribers > > against attacks by one of its own customers. For this reason uRPF and > > ACLs should be used on all interfaces facing subscribers. Filtering > > should be implemented with regard for the operational requirements of > > IPv6 (ICMPv6 types). > > > >==> I don't understand what you mean by the last sentence? > > @@@ > We probably used too few words. We wanted to say that while configuring IPv6 > ACLs, one has to make sure that the ACLs do not stop IPv6 specific controll > plane traffic (like ND, DHCP-PD etc). > @@@ I'd hope that folks wouldn't filter ICMPv6 at all, but that's probably too much to hope for.. remember, you cannot use e.g., 'ping' for host scanning purposes as you have about 2^64 potential hosts in a subnet... > > In IPv6, with [RFC3306] there is a better mechanism available for ASM > > IPv6 address allocation than in IPv4. This reduces the problems of > > using ASM in IPv6 to some degree. On the other hand, the protocol MSDP > > standard with PIM-SM is not currently defined for IPv6. In general, > > SSM for IPv6 is also considered to be the protocol to promote for the > > majority of future interdomain IP multicast applications and it is > > less complex solution to operate. > > > >==> you might want to check out and refer to > >draft-ietf-mboned-ipv6-multicast-issues-00.txt which discusses exactly this > >issue, and solutions if you'd still need ASM. > > @@@ > Yes, we are aware of this work and we will reference it. We didn't really > want to get into a model other then SSM despite the fact that there are > feasible > ways for ASM. The idea was that SPs will be more inclined to go for an SSM > model > at first (maybe even on a longer run) because of the business model of content > delivery (video/audio). Probably we should however have a discussion on the > topic. > Do you see the ASM discussion important beyond referencing the draft you > mentioned? > @@@ Well, ASM is what's used (or actually, not being widely used :) today, so it's a bit surprising to see it waved off just like that.. I guess it would be OK to mention ASM more briefly, and refer to possible solutions, but concentrate on SSM (and state the reasons for doing so, i.e., the easier business model for content delivery). > >6.2.1 POINT-TO-POINT MODEL > > > > > >==> this model has the built-in assumption that ATM is used as > >point-to-point. Is this strictly necessary, or could you just use any other > >media as well? > > @@@ > Could you please clarify this comment? > @@@ I meant that wouldn't it be possible to use e.g., Ethernet (instead of ATM) as the point-to-point uplink? I haven't seen this myself, but I've heard reports of such deployments.. > > If a Customer Router is present: > > > >[...] > > - it dynamically acquires through autoconfiguration the address for the > > link between itself and the Edge Router. This step is followed by a > > DHCP-PD [RFC 3633] request for a prefix shorter then /64 that in turn is > > divided in /64s and assigned to its interfaces connecting the hosts on > > the customer site. > > > >==> s/present/present, either:/ > > > >==> the router doesn't autoconfigure the address unless it has been > >configured to act as a host on its upstream interface... which would > >probably be bad practice.. so either the upstream link has no global > >addresses (which would be OK), or it could just use a subnet from the > >DHCP-PD prefix. > > @@@ > Why would you see it as a bad practice having the router acquire via stateless > autoconfig an address for the uplink to the provider? We should probably > discuss > all options for completeness purposes. > @@@ Well, if you have a router, I'd generally expect it to act as a router on all of its interfaces. There has been some debate of this mixed "host/router" behaviour on IPv6 WG list before, but I think the conclusion has been that mixed host/router is acceptable by the specs at least. I'd however personally rather see that the routers in these situations would have other means to configure an address (if they need one). > > MLD authentication, authorization and accounting is usually > > configured on the edge router in order to enable the ISP to do > > controll the subbscriber access of the service and do billing for > > the content provided. > > > >==> the non-standardized methods for adding AAA to IGMP/MLD have been > >proposed, but they're generally considered very broken models, and I'm not > >sure how much text we should have about them, at least without disclaimers. > >The right thing to do would probably be to encrypt the data, and provide the > >decryption key only to those who pay (or whatever for the stream. > > @@@ > We believe that such a feature is important to all SPs that deploy > mcast services for video and audio streaming. Maybe this is not > critical at the start of the service but would be when the service > offering solidifies. Such a feature offers more granularity in > controlling and charging a customer then the key proposal. With the > key proposal the user would have access to possibly a predefined > package of channels while with proper MLD AAA the user can select > any channel, any time and be charged only for that use. > @@@ These arguments should maybe go in the draft, but still keep in mind that MLD/IGMP have not been meant to authenticate the users. I'd expect that the same features can be obtained with encrypted data. You would get the key which would be valid only for some time from a web server, and that key would be only valid for a certain stream. That way you could get the keys etc. only only those parts of the transmission you'd want. There are possibly other approaches. MSEC (http://www.ietf.org/html.charters/msec-charter.html) WG has been looking at this problem. -- 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 Tue Sep 7 14:33:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18732 for ; Tue, 7 Sep 2004 14:33:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4kkM-000L58-8v for v6ops-data@psg.com; Tue, 07 Sep 2004 18:31:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4kkA-000L46-NO for v6ops@ops.ietf.org; Tue, 07 Sep 2004 18:31:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i87IV0n09630 for ; Tue, 7 Sep 2004 21:31:01 +0300 Date: Tue, 7 Sep 2004 21:31:00 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: REVIEW NEEDED: zeroconf requirements document (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (co-chair hat on) Folks, We MUST get more review on draft-nielsen-v6ops-zeroconf-goals-01.txt ASAP. There have been only a couple of comments. This is extremely important work -- please note that it could include a lot more than "just" the requirements for 3GPP tunneling. Please provide your input ASAP! (hat off) ---------- Forwarded message ---------- Date: Wed, 1 Sep 2004 12:27:59 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: REVIEW NEEDED: zeroconf requirements document Hi, (co-chair hat on) If you recall from the IETF60 meeting, we set out a couple of milestonoes and deadlines to make progress well before the next meeting -- and now the planning and scheduling for IETF61 has already started... We need to get more input especially on: http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-zeroconf-goals-01.txt Please read it and send feedback on the list. Please do this as soon as possible but on [7th] September at the latest. In particular, opinions on whether the document should include the applicability in the ISP networks (e.g., when the access network cannot be upgraded [which seems to have similar requirements as 3GPP]) would be highly appreciated. Thanks! (hat off) -- 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 Wed Sep 8 05:26:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24206 for ; Wed, 8 Sep 2004 05:26:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4yeh-0009dL-I5 for v6ops-data@psg.com; Wed, 08 Sep 2004 09:22:19 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4yeW-0009cS-0d for v6ops@ops.ietf.org; Wed, 08 Sep 2004 09:22:08 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3P004NUU06P2@mailout3.samsung.com> for v6ops@ops.ietf.org; Wed, 08 Sep 2004 18:21:42 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3P00HAVTYPLF@mailout3.samsung.com> for v6ops@ops.ietf.org; Wed, 08 Sep 2004 18:20:50 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3P00G3GTYM7M@mmp1.samsung.com> for v6ops@ops.ietf.org; Wed, 08 Sep 2004 18:20:49 +0900 (KST) Date: Wed, 08 Sep 2004 14:50:22 +0530 From: Radhakrishnan Suryanarayanan Subject: Comments on zeroconf draft To: juha.wiljakka@nokia.com Cc: V6OPS WG , Pekka Savola Reply-to: Radhakrishnan Suryanarayanan Message-id: <03ca01c49585$12a32fd0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_bFJpGOmwBzqVRgCvFBtmaw)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_bFJpGOmwBzqVRgCvFBtmaw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi Juha, Here are my first set of comments: section 6.3 "The tunnel protocol should allow the usage of native IPv6 connectivity whenever such is available." => Isnt this paragraph is redundant? the 3rd paragraph in this section says it all. section 6.5 " The discovery mechanism should rely on intrinsic services, read services already universally deployed, to the particular network ^^ environment." => should be "...in a particular environment." "It should not require the addition of additional IP network ..." ^^^^^^^^^^ => can be mentioned as "..addition of new IP network infrastructure..." section 6.6 " The tunnel protocol must allow for the assignment of at least one globally routable (/128) IPv6 unicast address to use for tunneled IPv6 connectivity over the link provided by the Zero-Configuration Tunneling mechanism. " => not very clear about the meaning of this paragraph. i guess it means that tunnel protocol gets a global IPv6 address before establishing a tunnel link for IPv6 connectivity. am i right? section 6.8 => does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power? Apart from this as i had already mentioned in my previous mails about a thought of expanding the applicability of this document beyond 3GPP. Maybe this is for the WG chair to decide. Thanks Radhakrishnan --Boundary_(ID_bFJpGOmwBzqVRgCvFBtmaw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi Juha,
  Here are my first set of comments:
 
section 6.3
 "The tunnel protocol should allow the usage of native IPv6

 connectivity whenever such is available."

 

=> Isnt this paragraph is redundant? the 3rd paragraph in this section says it all.

 

section 6.5

" The discovery mechanism should rely on intrinsic services, read

   services already universally deployed, to the particular network

                                          ^^

   environment."

=> should be "...in a particular environment."

 

  "It should not require the addition of additional IP network ..."

                                         ^^^^^^^^^^ 

=>  can be mentioned as "..addition of new IP network infrastructure..."

 

section 6.6

"

   The tunnel protocol must allow for the assignment of at least one

   globally routable (/128) IPv6 unicast address to use for tunneled

   IPv6 connectivity over the link provided by the Zero-Configuration

   Tunneling mechanism.

"

=> not very clear about the meaning of this paragraph. i guess it means that tunnel protocol gets a global IPv6 address before establishing a tunnel link for IPv6 connectivity. am i right?

 

section 6.8

=> does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power?

 

Apart from this as i had already mentioned in my previous mails about a thought of expanding the applicability of this document beyond 3GPP. Maybe this is for the WG chair to decide.

 

Thanks

Radhakrishnan

      

--Boundary_(ID_bFJpGOmwBzqVRgCvFBtmaw)-- From owner-v6ops@ops.ietf.org Wed Sep 8 06:45:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28745 for ; Wed, 8 Sep 2004 06:45:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C4zuO-000HaI-3Z for v6ops-data@psg.com; Wed, 08 Sep 2004 10:42:36 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C4ztu-000HYc-Jk for v6ops@ops.ietf.org; Wed, 08 Sep 2004 10:42:07 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i88Ag2WR024774 for ; Wed, 8 Sep 2004 12:42:02 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Sep 2004 12:42:02 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SNXM2RF8; Wed, 8 Sep 2004 12:42:02 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Sep 2004 12:42:02 +0200 Message-ID: X-Sybari-Trust: 4f260426 74470f8f ebda6397 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com Cc: V6OPS WG , Pekka Savola Subject: RE: Comments on zeroconf draft Date: Wed, 8 Sep 2004 12:41:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C49590.772D1846" X-OriginalArrivalTime: 08 Sep 2004 10:42:02.0327 (UTC) FILETIME=[79B9DE70:01C49590] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C49590.772D1846 Content-Type: text/plain; charset="iso-8859-1" Hi Radhakrishnan, Thanks a lot for your comments. Please find my comments inline. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Radhakrishnan Suryanarayanan Sent: Wednesday, September 08, 2004 11:20 AM To: juha.wiljakka@nokia.com Cc: V6OPS WG; Pekka Savola Subject: Comments on zeroconf draft Hi Juha, Here are my first set of comments: section 6.3 "The tunnel protocol should allow the usage of native IPv6 connectivity whenever such is available." => Isnt this paragraph is redundant? the 3rd paragraph in this section says it all. [Karen E. Nielsen (AH/TED)] I believe that you're right. The first paragraph is a reminiscent from version 00. section 6.5 " The discovery mechanism should rely on intrinsic services, read services already universally deployed, to the particular network ^^ environment." => should be "...in a particular environment." "It should not require the addition of additional IP network ..." ^^^^^^^^^^ => can be mentioned as "..addition of new IP network infrastructure..." [Karen E. Nielsen (AH/TED)] , yes thanks. section 6.6 " The tunnel protocol must allow for the assignment of at least one globally routable (/128) IPv6 unicast address to use for tunneled IPv6 connectivity over the link provided by the Zero-Configuration Tunneling mechanism. " => not very clear about the meaning of this paragraph. i guess it means that tunnel protocol gets a global IPv6 address before establishing a tunnel link for IPv6 connectivity. am i right? [Karen E. Nielsen (AH/TED)] - The intended meaning of the paragraph is to say: "The tunnel protocol must allow for the assignment of at least one globally routable (/128) IPv6 unicast address to the end-hosts, which the end-hosts can use for IPv6 communication through the zero-configuration tunnels." Is that clearer ? section 6.8 => does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power? [Karen E. Nielsen (AH/TED)] NUD should be OK Radio power wise. The reason NUD is not explicitly referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks. Apart from this as i had already mentioned in my previous mails about a thought of expanding the applicability of this document beyond 3GPP. Maybe this is for the WG chair to decide. [Karen E. Nielsen (AH/TED)] Thanks for your comments in that respect also. Narrowing the document to 3GPP as starting point has served its own purposes: * 3GPP has severe timing requirements, wherefore this case has the highest priority. * It has been claimed that the assisted tunnelling requirements wasn't adequate for 3GPP, wherefore it has been important to see exactly how these requirements differs from the requirements of assisted-tunnelling - Now given that we have the requirements, this document could be used to decide: * Initial: whether the 3GPP case is sufficiently different from assisted tunnelling for it to have its on life requirements wise (and solution wise) - (if not the timing requirements alone makes it necessary for it to have its own life). * Subsequently: if zeroconf tunneling as a concept is granted its own life, are there additional scenarios where this may be applicable. Further are the additional requirements that should be served by zeroconf tunnelling so that it will be applicable to additional scenarios, which do not fit within the framework of assisted tunnelling. Thanks. Karen Thanks Radhakrishnan ------_=_NextPart_001_01C49590.772D1846 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Radhakrishnan,
 
Thanks=20 a lot for your comments.
 
Please=20 find my comments inline.
 
-----Original Message-----
From: = owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Radhakrishnan=20 Suryanarayanan
Sent: Wednesday, September 08, 2004 11:20=20 AM
To: juha.wiljakka@nokia.com
Cc: V6OPS WG; = Pekka=20 Savola
Subject: Comments on zeroconf = draft

Hi Juha,
  Here are my first set of = comments:
 
section 6.3
 "The tunnel=20 protocol should allow the usage of native = IPv6

 connectivity=20 whenever such is available."

 

=3D> Isnt this=20 paragraph is redundant? the 3rd paragraph in this section says it=20 all.
 
[Karen E. Nielsen = (AH/TED)]  I believe that = you're right. The=20 first paragraph is a reminiscent from version = 00.

 

section=20 6.5

" The discovery mechanism should rely on intrinsic = services,=20 read

  =20 services already universally deployed, to the particular=20 network

          &nb= sp;           &nb= sp;           &nb= sp;      =20 ^^

  =20 environment."

=3D> should be "...in a particular = environment."

 

  "It should not require the addition of additional IP = network=20 ..."

          &nb= sp;           &nb= sp;           &nb= sp;      ^^^^^^^^^^ =20

=3D>  can=20 be mentioned as "..addition of new IP network = infrastructure..."
 
[Karen E. Nielsen=20 (AH/TED)] , yes thanks. 

 

section=20 6.6

"

  =20 The tunnel protocol must allow for the assignment of at least=20 one

  =20 globally routable (/128) IPv6 unicast address to use for=20 tunneled

  =20 IPv6 connectivity over the link provided by the=20 Zero-Configuration

  =20 Tunneling mechanism.

"

=3D> not very=20 clear about the meaning of this paragraph. i guess it means that = tunnel=20 protocol gets a global IPv6 address before establishing a = tunnel=20 link for IPv6 connectivity. am i right?
 
[Karen E. Nielsen=20 (AH/TED)] - The intended meaning of the paragraph is to=20 say:

"The tunnel protocol must allow for the = assignment of at=20 least one

   globally routable = (/128) IPv6=20 unicast address  to the end-hosts, = which=20 the

end-hosts can=20 use for = IPv6=20 communication through the zero-configuration = tunnels."

 

Is that clearer = ?

 

section=20 6.8

=3D> does=20 NUD (in section 3.8 in RFC 2893) helps? or does it help NOT = having it for=20 sake of saving Radio power?
 
[Karen E. Nielsen (AH/TED)]  NUD should = be OK=20 Radio power wise. The reason NUD is not explicitly referred to in = Section 6.8,=20 but unicast NS/NA exchanges are, is that by NUD one tends to = understand the=20 full mechanism described in Section 7.3 of RFC 2461, and this = requires=20 link-local multicast support - which we do not explicitly = assume/require.=20 Further there may be issues with NUD if it is required to be = performed by the=20 tunnel servers, as NUD on routers is susceptible to DoS=20 attacks.

 

Apart from this=20 as i had already mentioned in my previous mails about a thought of = expanding=20 the applicability of this document beyond 3GPP. Maybe this is for the = WG chair=20 to decide.
 
[Karen E. Nielsen (AH/TED)] Thanks for your = comments in=20 that respect also. 

Narrowing the=20 document to 3GPP as starting point has served its = own=20 purposes:

* 3GPP has severe timing = requirements,=20 wherefore this case has the highest priority.

* It has been claimed that = the assisted=20 tunnelling requirements wasn't adequate for 3GPP, wherefore it has = been=20 important to

see exactly how these = requirements=20 differs from the requirements of assisted-tunnelling - =

 

Now given that we have the = requirements,=20 this document could be used to decide:

 

* Initial: whether the 3GPP = case is=20 sufficiently different from assisted tunnelling for it to have its on = life=20 requirements wise

(and solution wise) - (if = not the timing=20 requirements alone makes it necessary for it to have its own=20 life).

 

* Subsequently: if zeroconf = tunneling as=20 a concept is granted its own life, are there additional scenarios = where this=20 may be applicable.

Further are the additional = requirements=20 that should be served by zeroconf tunnelling so that it will be=20 applicable to additional scenarios, which do not fit = within the=20 framework of assisted tunnelling.

 

 

Thanks. = Karen

 

Thanks

Radhakrishnan=20

      

------_=_NextPart_001_01C49590.772D1846-- From owner-v6ops@ops.ietf.org Wed Sep 8 07:00:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29697 for ; Wed, 8 Sep 2004 07:00:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C50BA-000Jj9-GO for v6ops-data@psg.com; Wed, 08 Sep 2004 10:59:56 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C50Az-000Ji9-J7 for v6ops@ops.ietf.org; Wed, 08 Sep 2004 10:59:45 +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 i88Axdgg006754; Wed, 8 Sep 2004 11:59:39 +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 LAA09954; Wed, 8 Sep 2004 11:59:31 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i88AxVu09672; Wed, 8 Sep 2004 11:59:31 +0100 Date: Wed, 8 Sep 2004 11:59:31 +0100 From: Tim Chown To: sc@uk.ipv6tf.org Subject: UK IPv6 Deployment Conference, 24th Sep Message-ID: <20040908105931.GI7326@login.ecs.soton.ac.uk> Mail-Followup-To: sc@uk.ipv6tf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, The UK IPv6 Task Force, in conjunction with RIPE and the European IST IPv6 Cluster, is presenting a programme of IPv6 events from 23rd-24th September 2004. The UK IPv6 Deployment Conference, sponsored by BT and Cisco, is being held on 24th September and is targeted at those interested in the current state of play in IPv6 deployment. It aims to present an overview of state-of-the-art in the latest IPv6 deployment technology, including: * Advanced testbeds, including the US Moonv6 project * Early IPv6 production deployments, in backbones and enterprises * IPv4-IPv6 transition and integration technologies * IPv6 opportunities: new technologies, delivery media and applications The Conference is co-located with the 49th RIPE Meeting of 20th-24th September, at which Europe's ISPs will gather to discuss technology and policy. We have scheduled a free European IST IPv6 Cluster meeting - focusing on IPv6 research - on the afternoon before the UK IPv6 Deployment Conference to allow our delegates the opportunity of attending an attractive, fuller one-and-a-half day programme of leading edge IPv6 talks and discussion should they wish to do so. For full details and registration information, please see: http://www.uk.ipv6tf.org/events/manchester.html Hope to see you in Manchester! Regards, Tim Chown On behalf of the UK IPv6 Task Force Steering Committee From owner-v6ops@ops.ietf.org Wed Sep 8 07:15:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00636 for ; Wed, 8 Sep 2004 07:15:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C50PW-000LXq-9g for v6ops-data@psg.com; Wed, 08 Sep 2004 11:14:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C50PL-000LVs-Bu for v6ops@ops.ietf.org; Wed, 08 Sep 2004 11:14:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i88BEPT30686; Wed, 8 Sep 2004 14:14:26 +0300 Date: Wed, 8 Sep 2004 14:14:25 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: "'Radhakrishnan Suryanarayanan'" , , V6OPS WG Subject: RE: Comments on zeroconf draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk My personal opinions only. On Wed, 8 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > Apart from this as i had already mentioned in my previous mails > about a thought of expanding the applicability of this document > beyond 3GPP. Maybe this is for the WG chair to decide. > > [Karen E. Nielsen (AH/TED)] Thanks for your comments in that respect also. [...] > > Now given that we have the requirements, this document could be used > to decide: > > * Initial: whether the 3GPP case is sufficiently different from > assisted tunnelling for it to have its on life requirements wise I'd say, no, "zeroconf" requirements are common enough; some are 3GPP-specific, but many are not. Then a logical approach would seem to be have a "generic requirements" section (which would still be sufficiently grounded in the operational scenarios), and sections on specific requirements under different scenarios. > (and solution wise) - (if not the timing requirements alone makes it > necessary for it to have its own life). IMHO, as this is just the requirements, the solutions could be the same or not if everything was done under the label of "zeroconf", so I don't see this as a big factor. > * Subsequently: if zeroconf tunneling as a concept is granted its > own life, are there additional scenarios where this may be > applicable. > > Further are the additional requirements that should be served by > zeroconf tunnelling so that it will be applicable to additional > scenarios, which do not fit within the framework of assisted > tunnelling. IMHO, yes. I can't see additional requirements which weren't there under the assisted tunneling. Remember that assisted tunneling went out to provide requirements for two different cases: "zero-conf -like", and "controlled". Now that there is draft out on "zero-conf -like", it doesn't seem to be useful to cover that under assisted tunneling, but just make it cover "controlled". Overlap won't do us any good.. -- 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 Wed Sep 8 10:25:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15561 for ; Wed, 8 Sep 2004 10:25:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C53Lh-000GAo-T8 for v6ops-data@psg.com; Wed, 08 Sep 2004 14:23:01 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C53LW-000G9e-LH for v6ops@ops.ietf.org; Wed, 08 Sep 2004 14:22:50 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3Q00J5E7Y0XO@mailout1.samsung.com> for v6ops@ops.ietf.org; Wed, 08 Sep 2004 23:22:48 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3Q009167DIS6@mailout1.samsung.com> for v6ops@ops.ietf.org; Wed, 08 Sep 2004 23:10:30 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3Q00GAW7DGHN@mmp1.samsung.com> for v6ops@ops.ietf.org; Wed, 08 Sep 2004 23:10:30 +0900 (KST) Date: Wed, 08 Sep 2004 19:40:04 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: Comments on zeroconf draft To: "Karen E. Nielsen (AH/TED)" , juha.wiljakka@nokia.com Cc: V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <047101c495ad$8aa3d4d0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_IsFJzcKn1XHD5zNXi6GGPA)" X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_IsFJzcKn1XHD5zNXi6GGPA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi Karen, Please find my points inline:- section 6.6 >" > The tunnel protocol must allow for the assignment of at least one > globally routable (/128) IPv6 unicast address to use for tunneled > IPv6 connectivity over the link provided by the Zero-Configuration > Tunneling mechanism. >" >=> not very clear about the meaning of this paragraph. i guess it means that tunnel protocol gets a >global IPv6 address before establishing a tunnel link for IPv6 connectivity. am i right? >[Karen E. Nielsen (AH/TED)] - The intended meaning of the paragraph is to say: >"The tunnel protocol must allow for the assignment of at least one > globally routable (/128) IPv6 unicast address to the end-hosts, which the >end-hosts can use for IPv6 communication through the zero-configuration tunnels." >Is that clearer ? => Fairly yes. The meaning is end-host is going to get a IPv6 global address through the established tunnel. >section 6.8 >=> does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power? >[Karen E. Nielsen (AH/TED)] NUD should be OK Radio power wise. The reason NUD is not explicitly >referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the >full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - >which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be >performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks. =>Thats why i stated section 3.8 in RFC 2893. Cant we make it that explicit? I am trying to see if we can make zeroconf fall in-line with whats stated in RFC 2893 which is about "Transition Mechanisms for IPv6 hosts and Routers". Thanks Radhakrishnan --Boundary_(ID_IsFJzcKn1XHD5zNXi6GGPA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi Karen,
   Please find my points inline:-
section 6.6
>"
>   The tunnel protocol must allow for the assignment of at least one
>   globally routable (/128) IPv6 unicast address to use for tunneled
>   IPv6 connectivity over the link provided by the Zero-Configuration
>   Tunneling mechanism.
>"
>=> not very clear about the meaning of this paragraph. i guess it means that tunnel protocol gets a >global IPv6 address before establishing a tunnel link for IPv6 connectivity. am i right?
 
>[Karen E. Nielsen (AH/TED)] - The intended meaning of the paragraph is to say:
>"The tunnel protocol must allow for the assignment of at least one
>  globally routable (/128) IPv6 unicast address  to the end-hosts, which the
>end-hosts can use for IPv6 communication through the zero-configuration tunnels."

>Is that clearer ?
 
=> Fairly yes. The meaning is end-host is going to get a IPv6 global address through the established tunnel.

>section 6.8
>=> does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power?
 
>[Karen E. Nielsen (AH/TED)]  NUD should be OK Radio power wise. The reason NUD is not explicitly >referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the >full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - >which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be >performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks.
=>Thats why i stated section 3.8 in RFC 2893. Cant we make it that explicit?
I am trying to see if we can make zeroconf fall in-line with whats stated in RFC 2893 which is about "Transition Mechanisms for IPv6 hosts and Routers".

Thanks
Radhakrishnan
--Boundary_(ID_IsFJzcKn1XHD5zNXi6GGPA)-- From owner-v6ops@ops.ietf.org Thu Sep 9 01:08:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03233 for ; Thu, 9 Sep 2004 01:08:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5H88-0002DM-Jf for v6ops-data@psg.com; Thu, 09 Sep 2004 05:05:56 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5H7x-0002Bh-DL for v6ops@ops.ietf.org; Thu, 09 Sep 2004 05:05:45 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3R00681CSXYD@mailout1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 14:05:21 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3R00NIGCHT3I@mailout1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 13:58:42 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3R00B0CCHS2N@mmp2.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 13:58:41 +0900 (KST) Date: Thu, 09 Sep 2004 10:28:14 +0530 From: Radhakrishnan Suryanarayanan Subject: more comments on zeroconf draft To: "Karen E. Nielsen (AH/TED)" Cc: V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <04c501c49629$9e229ab0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_AlrNtEhmtikCTl2dsADE1Q)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_60_70, HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_AlrNtEhmtikCTl2dsADE1Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi Karen, Please find more comments on the draft: section 9.1 "...drop policies, either simple drop all protocol-41 policies or more..." ^^^^^^^^^ => Packets you mean? Section 9.2 " Here it is implicitly assumed that the tunnel server(s) take the role of default routers and the end-nodes using Zero-Configuration Tunneling for IPv6 connectivity the role of hosts in multi-access environments. " => For sake clarity can we re-phrase this paragraph as follows? "Here it is implicitly assumed that: - the tunnel server(s) take the role of default routers - the end-nodes which use Zero-Configuration Tunneling for IPv6 connectivity assume the role of hosts in multi-access environments." --Boundary_(ID_AlrNtEhmtikCTl2dsADE1Q) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi Karen,
  Please find more comments on the draft:
 
 
section 9.1
"...drop policies, either simple drop all protocol-41 policies or more..."
                                                                             ^^^^^^^^^
=> Packets you mean?
 
Section 9.2
"

   Here it is implicitly assumed that the tunnel server(s) take the role

   of default routers and the end-nodes using Zero-Configuration

   Tunneling for IPv6 connectivity the role of hosts in multi-access

   environments.

"
=> For sake clarity can we re-phrase this paragraph as follows?

   "Here it is implicitly assumed that:

    - the tunnel server(s) take the role of default routers 

    - the end-nodes which use Zero-Configuration Tunneling for IPv6

       connectivity assume the role of hosts in multi-access environments."

 

 
--Boundary_(ID_AlrNtEhmtikCTl2dsADE1Q)-- From owner-v6ops@ops.ietf.org Thu Sep 9 03:02:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23762 for ; Thu, 9 Sep 2004 03:02:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5Iv5-000D1n-Sk for v6ops-data@psg.com; Thu, 09 Sep 2004 07:00:35 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5Ius-000D0M-FI for v6ops@ops.ietf.org; Thu, 09 Sep 2004 07:00:22 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8970LWR014090 for ; Thu, 9 Sep 2004 09:00:21 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 09:00:20 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SQKM2K40; Thu, 9 Sep 2004 09:00:21 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Sep 2004 09:00:20 +0200 Message-ID: X-Sybari-Trust: cc968e50 477d8de1 d8e0e1f9 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" Cc: V6OPS WG Subject: RE: Comments on zeroconf draft Date: Thu, 9 Sep 2004 09:00:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4963A.AA97E468" X-OriginalArrivalTime: 09 Sep 2004 07:00:20.0943 (UTC) FILETIME=[ABE57DF0:01C4963A] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4963A.AA97E468 Content-Type: text/plain; charset="iso-8859-1" Hi Radhakrishnan, ----- >[Karen E. Nielsen (AH/TED)] - The intended meaning of the paragraph is to say: >"The tunnel protocol must allow for the assignment of at least one > globally routable (/128) IPv6 unicast address to the end-hosts, which the >end-hosts can use for IPv6 communication through the zero-configuration tunnels." >Is that clearer ? => Fairly yes. The meaning is end-host is going to get a IPv6 global address through the established tunnel. [Karen E. Nielsen (AH/TED)] There are no goals as to how exactly the end-host should acquire the address - it is not a _goal_ that the address must be allocated through the established tunnel, but I know of many solutions that do it that way. >section 6.8 >=> does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power? >[Karen E. Nielsen (AH/TED)] NUD should be OK Radio power wise. The reason NUD is not explicitly >referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the >full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - >which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be >performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks. =>Thats why i stated section 3.8 in RFC 2893. Cant we make it that explicit? I am trying to see if we can make zeroconf fall in-line with whats stated in RFC 2893 which is about "Transition Mechanisms for IPv6 hosts and Routers". [Karen E. Nielsen (AH/TED)] No we can not use RFC2893, well perhaps we could have, but RFC 2893 is in the process of being deprecated - and the corresponding section, Section 3.8, in its replacement, http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-06.txt , does not apply as it speaks about configured tunnels with point-to-point link capabilities (including link-local multicast) and I see not explicit requirements for zero-conf to provide this - do you ? Thanks, Karen ------_=_NextPart_001_01C4963A.AA97E468 Content-Type: text/html; charset="iso-8859-1"
Hi Radhakrishnan,
----- 
>[Karen E. Nielsen (AH/TED)] - The intended meaning of the paragraph is to say:
>"The tunnel protocol must allow for the assignment of at least one
>  globally routable (/128) IPv6 unicast address  to the end-hosts, which the
>end-hosts can use for IPv6 communication through the zero-configuration tunnels."

>Is that clearer ?
 
=> Fairly yes. The meaning is end-host is going to get a IPv6 global address through the established tunnel.
 
[Karen E. Nielsen (AH/TED)] There are no goals as to how exactly the end-host should
acquire the address  - it is not a _goal_ that the address must be allocated through the established tunnel, but I know
of many solutions that do it that way.
 
>section 6.8
>=> does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power?
 
>[Karen E. Nielsen (AH/TED)]  NUD should be OK Radio power wise. The reason NUD is not explicitly >referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the >full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - >which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be >performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks.
=>Thats why i stated section 3.8 in RFC 2893. Cant we make it that explicit?
I am trying to see if we can make zeroconf fall in-line with whats stated in RFC 2893 which is about "Transition Mechanisms for IPv6 hosts and Routers".
 
[Karen E. Nielsen (AH/TED)] No we can not use RFC2893, well perhaps we could have, but RFC 2893 is in the process of
being deprecated - and the corresponding section, Section 3.8, in
its replacement, http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-06.txt, does not apply as it speaks about configured tunnels with point-to-point link capabilities (including link-local multicast) and I see not explicit requirements for zero-conf to
provide this - do you ?
 
Thanks, Karen
------_=_NextPart_001_01C4963A.AA97E468-- From owner-v6ops@ops.ietf.org Thu Sep 9 03:04:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23877 for ; Thu, 9 Sep 2004 03:04:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5IyG-000DPz-Be for v6ops-data@psg.com; Thu, 09 Sep 2004 07:03:52 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5Ixx-000DNJ-6b for v6ops@ops.ietf.org; Thu, 09 Sep 2004 07:03:33 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8973WAh000224 for ; Thu, 9 Sep 2004 09:03:32 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 09:03:31 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SMGSVV9B; Thu, 9 Sep 2004 09:03:32 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Sep 2004 09:03:31 +0200 Message-ID: X-Sybari-Trust: bfaa261b 477d8de1 d8e0e1f9 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" Cc: V6OPS WG Subject: RE: more comments on zeroconf draft Date: Thu, 9 Sep 2004 09:03:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4963A.CAAB17A4" X-OriginalArrivalTime: 09 Sep 2004 07:03:31.0930 (UTC) FILETIME=[1DBBCBA0:01C4963B] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4963A.CAAB17A4 Content-Type: text/plain; charset="iso-8859-1" Hi, section 9.1 "...drop policies, either simple drop all protocol-41 policies or more..." ^^^^^^^^^ => Packets you mean? [Karen E. Nielsen (AH/TED)] Yes, thanks. Section 9.2 " Here it is implicitly assumed that the tunnel server(s) take the role of default routers and the end-nodes using Zero-Configuration Tunneling for IPv6 connectivity the role of hosts in multi-access environments. " => For sake clarity can we re-phrase this paragraph as follows? "Here it is implicitly assumed that: - the tunnel server(s) take the role of default routers - the end-nodes which use Zero-Configuration Tunneling for IPv6 connectivity assume the role of hosts in multi-access environments." [Karen E. Nielsen (AH/TED)] Sure, thanks for the clarification. BR, Karen ------_=_NextPart_001_01C4963A.CAAB17A4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
section 9.1
"...drop=20 policies, either simple drop all protocol-41 policies or=20 more..."
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      ^^^^^^^^^
=3D> Packets you = mean?
[Karen E. Nielsen=20 (AH/TED)] 
Yes, thanks.
 
Section 9.2
"=20

   = Here it=20 is implicitly assumed that the tunnel server(s) take the=20 role

   = of=20 default routers and the end-nodes using=20 Zero-Configuration

  =20 Tunneling for IPv6 connectivity the role of hosts in=20 multi-access

  =20 environments.

"
=3D> For sake clarity can = we re-phrase this=20 paragraph as follows?

  =20 "Here it is implicitly assumed that:

    - the tunnel server(s) = take the=20 role of=20 default routers 

    - the end-nodes which = use=20 Zero-Configuration Tunneling for IPv6 =

       connectivity = assume the role=20 of hosts in multi-access environments."
[Karen E. Nielsen=20 (AH/TED)] 

Sure, = thanks for the=20 clarification.

 

BR,=20 = Karen 

------_=_NextPart_001_01C4963A.CAAB17A4-- From owner-v6ops@ops.ietf.org Thu Sep 9 03:23:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24678 for ; Thu, 9 Sep 2004 03:23:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5JG1-000FWv-A3 for v6ops-data@psg.com; Thu, 09 Sep 2004 07:22:13 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5JFq-000FVM-BL for v6ops@ops.ietf.org; Thu, 09 Sep 2004 07:22:02 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3R0075OJ4PEJ@mailout1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 16:22:01 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3R00CT4IX8C9@mailout1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 16:17:32 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3R00BT3IX62N@mmp2.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 16:17:32 +0900 (KST) Date: Thu, 09 Sep 2004 12:47:04 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: Comments on zeroconf draft To: "Karen E. Nielsen (AH/TED)" Cc: V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <050d01c4963d$032d04f0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_awCZxYSdoV8ZMduIOhRFXg)" X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_awCZxYSdoV8ZMduIOhRFXg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi Karen, Fair. Thanks a lot for clarifying. :-) Regards Radhakrishnan ----- Original Message ----- From: Karen E. Nielsen (AH/TED) To: 'Radhakrishnan Suryanarayanan' Cc: V6OPS WG Sent: Thursday, September 09, 2004 12:30 PM Subject: RE: Comments on zeroconf draft Hi Radhakrishnan, ----- >[Karen E. Nielsen (AH/TED)] - The intended meaning of the paragraph is to say: >"The tunnel protocol must allow for the assignment of at least one > globally routable (/128) IPv6 unicast address to the end-hosts, which the >end-hosts can use for IPv6 communication through the zero-configuration tunnels." >Is that clearer ? => Fairly yes. The meaning is end-host is going to get a IPv6 global address through the established tunnel. [Karen E. Nielsen (AH/TED)] There are no goals as to how exactly the end-host should acquire the address - it is not a _goal_ that the address must be allocated through the established tunnel, but I know of many solutions that do it that way. >section 6.8 >=> does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power? >[Karen E. Nielsen (AH/TED)] NUD should be OK Radio power wise. The reason NUD is not explicitly >referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the >full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - >which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be >performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks. =>Thats why i stated section 3.8 in RFC 2893. Cant we make it that explicit? I am trying to see if we can make zeroconf fall in-line with whats stated in RFC 2893 which is about "Transition Mechanisms for IPv6 hosts and Routers". [Karen E. Nielsen (AH/TED)] No we can not use RFC2893, well perhaps we could have, but RFC 2893 is in the process of being deprecated - and the corresponding section, Section 3.8, in its replacement, http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-06.txt, does not apply as it speaks about configured tunnels with point-to-point link capabilities (including link-local multicast) and I see not explicit requirements for zero-conf to provide this - do you ? Thanks, Karen --Boundary_(ID_awCZxYSdoV8ZMduIOhRFXg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi Karen,
  Fair. Thanks a lot for clarifying. :-)
 
Regards
Radhakrishnan
----- Original Message -----
Sent: Thursday, September 09, 2004 12:30 PM
Subject: RE: Comments on zeroconf draft

Hi Radhakrishnan,
----- 
>[Karen E. Nielsen (AH/TED)] - The intended meaning of the paragraph is to say:
>"The tunnel protocol must allow for the assignment of at least one
>  globally routable (/128) IPv6 unicast address  to the end-hosts, which the
>end-hosts can use for IPv6 communication through the zero-configuration tunnels."

>Is that clearer ?
 
=> Fairly yes. The meaning is end-host is going to get a IPv6 global address through the established tunnel.
 
[Karen E. Nielsen (AH/TED)] There are no goals as to how exactly the end-host should
acquire the address  - it is not a _goal_ that the address must be allocated through the established tunnel, but I know
of many solutions that do it that way.

>section 6.8
>=> does NUD (in section 3.8 in RFC 2893) helps? or does it help NOT having it for sake of saving Radio power?
 
>[Karen E. Nielsen (AH/TED)]  NUD should be OK Radio power wise. The reason NUD is not explicitly >referred to in Section 6.8, but unicast NS/NA exchanges are, is that by NUD one tends to understand the >full mechanism described in Section 7.3 of RFC 2461, and this requires link-local multicast support - >which we do not explicitly assume/require. Further there may be issues with NUD if it is required to be >performed by the tunnel servers, as NUD on routers is susceptible to DoS attacks.
=>Thats why i stated section 3.8 in RFC 2893. Cant we make it that explicit?
I am trying to see if we can make zeroconf fall in-line with whats stated in RFC 2893 which is about "Transition Mechanisms for IPv6 hosts and Routers".
 
[Karen E. Nielsen (AH/TED)] No we can not use RFC2893, well perhaps we could have, but RFC 2893 is in the process of
being deprecated - and the corresponding section, Section 3.8, in
its replacement, http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-06.txt, does not apply as it speaks about configured tunnels with point-to-point link capabilities (including link-local multicast) and I see not explicit requirements for zero-conf to
provide this - do you ?
 
Thanks, Karen
--Boundary_(ID_awCZxYSdoV8ZMduIOhRFXg)-- From owner-v6ops@ops.ietf.org Thu Sep 9 05:11:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29815 for ; Thu, 9 Sep 2004 05:11:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5KvR-000Pr3-Sd for v6ops-data@psg.com; Thu, 09 Sep 2004 09:09:05 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5KvH-000Ppu-1v for v6ops@ops.ietf.org; Thu, 09 Sep 2004 09:08:55 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3R0050DO2SEP@mailout3.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 18:08:53 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3R00FQHO2S5B@mailout3.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 18:08:52 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3R00DISO2PWE@mmp2.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 18:08:52 +0900 (KST) Date: Thu, 09 Sep 2004 14:38:23 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: Comments on zeroconf draft To: "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Cc: juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" , V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <053501c4964c$9095bdf0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Karen, > > > - plus keep alive messages > > > > .. which the client may choose not to send. > > Yes, but, quote: > "but [the client] should then expect that the tunnel may be > disconnected at any time by the ISP and be prepared to restart the > set-up phase" I dont think its hard to convince the authors of assisted tunneling draft to change the "SHOULD to "MAY". In 3GPP networks, the ISP can always switch off the keepalive messages & then the question of tearing down of a tunnel from ISP might not as well happen at all. > > > > > - plus IPv6 dns registration by server side > > > > .. which is practically an implementation issue at the server side, > > because the protocol is explicitly not required to support this. > > > > Yes, that is what is being said (:-) But if you think about it > this puts requirements on the tunnel protocol. > As a minimum the server must be able to ascertain when a certain node > (identified by something - the IPv4-address ?) is reachable and > not-reachable at a certain IPv6-address. IMHO, this is not a problem. Please see the quote below " If stable prefix delegation is done, it is expected that the DNS delegation of the associated reverse DNS zone will be also stable and thus can be performed out of band, so there is no requirement to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ perform this delegation at the tunnel set-up time." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The authors of assisted-tunnelling have only thought about stateful > mechs, I think. Have the authors of zeroconf requirements have any stateless mech in mind? I feel that every tunnel server WILL have to maintain a min. set of client parameters implicitly making it stateful. From owner-v6ops@ops.ietf.org Thu Sep 9 05:14:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00026 for ; Thu, 9 Sep 2004 05:14:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5L0L-0000Fi-6J for v6ops-data@psg.com; Thu, 09 Sep 2004 09:14:09 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5L08-0000Ed-9R for v6ops@ops.ietf.org; Thu, 09 Sep 2004 09:13:56 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i899DtAh019636 for ; Thu, 9 Sep 2004 11:13:55 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 11:13:55 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SMGSXGZG; Thu, 9 Sep 2004 11:13:54 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Sep 2004 11:13:54 +0200 Message-ID: X-Sybari-Trust: 514dab50 477d8de1 d8e0e1f9 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" , "'Pekka Savola'" Cc: juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" , V6OPS WG Subject: RE: Comments on zeroconf draft Date: Thu, 9 Sep 2004 11:13:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Sep 2004 09:13:55.0341 (UTC) FILETIME=[54D993D0:01C4964D] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > The authors of assisted-tunnelling have only thought about stateful > > mechs, I think. > Have the authors of zeroconf requirements have any stateless > mech in mind? > I feel that every tunnel server WILL have to maintain a min. > set of client > parameters implicitly making it stateful. > I know of at least one stateless protocol which comply with the zeroconf goals. I do not see any requirements for the mechanism to be stateful. A tunnel server may want to implement some kind of NUD-like mech to prevent black holes, but that's different. Which are the parameters that you consider to be a must (for zeroconf that is) ? BR, Karen From owner-v6ops@ops.ietf.org Thu Sep 9 05:40:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01865 for ; Thu, 9 Sep 2004 05:40:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5LNW-0002cM-N3 for v6ops-data@psg.com; Thu, 09 Sep 2004 09:38:06 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5LNM-0002bX-22 for v6ops@ops.ietf.org; Thu, 09 Sep 2004 09:37:56 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3R005BUPF7R1@mailout1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 18:37:55 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3R00C9APBMC9@mailout1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 18:35:46 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3R00EZ0PBJGU@mmp2.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 18:35:46 +0900 (KST) Date: Thu, 09 Sep 2004 15:05:18 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: Comments on zeroconf draft To: "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" Cc: juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" , V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <056701c49650$52cbe220$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi karen, I have some doubts. Can you clarify this point? The quote from the zerconf draft : " Tunnel state here is considered to be any parameter kept by the server per client and without which the server is unable to serve the client (receive packets from/send packets to). " Isnt the client's/end-node's v6address reachability using the v6-in-v4 tunnel itself a parameter maintained at the tunnel server? If so, then doesnt that itself means a tunnel state? From owner-v6ops@ops.ietf.org Thu Sep 9 05:58:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02720 for ; Thu, 9 Sep 2004 05:58:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5Lfu-0004pS-NW for v6ops-data@psg.com; Thu, 09 Sep 2004 09:57:06 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5Lfb-0004nL-OS for v6ops@ops.ietf.org; Thu, 09 Sep 2004 09:56:48 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i899ukWR009448 for ; Thu, 9 Sep 2004 11:56:46 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 11:56:46 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SMGSXYLQ; Thu, 9 Sep 2004 11:56:45 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Sep 2004 11:56:45 +0200 Message-ID: X-Sybari-Trust: bab7d091 477d8de1 d8e0e1f9 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" , "'Pekka Savola'" Cc: juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" , V6OPS WG Subject: RE: Comments on zeroconf draft Date: Thu, 9 Sep 2004 11:56:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Sep 2004 09:56:46.0426 (UTC) FILETIME=[515603A0:01C49653] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Radhakrisnan, > > > Hi karen, > I have some doubts. Can you clarify this point? > The quote from the zerconf draft : > " > Tunnel state here is considered to be any parameter kept by the > > server per client and without which the server is unable > to serve the > > client (receive packets from/send packets to). > > " > Isnt the client's/end-node's v6address reachability using the v6-in-v4 > tunnel itself a parameter maintained at the tunnel server? If so, then > doesnt that itself means a tunnel state? > If the mechanism is stateless, the v6 address of the clients need not be maintained at the server. I think you know that - but I just want to be absolutely clear. Goal 6.8 is there first and foremost to allow for NUD like mechanism to be performed by the tunnel clients so that they, if need arises, can ascertain the reachability of their tunnel servers as well as the reachability of peers in the direct tunnelling situation. I can see that this should be clarified in the draft. IF a Tunnel Server performs a NUD like mech on the clients it serves, it must of course maintain reachability state as you describe. Normally last hops routers performs NUD so that they can send ICMPs back to origin to notify of black holes/unreachability. Personally I am not sure that this is a MUST requirement on the Tunnel Servers. I have actually thought that we could avoid this, especially since we have no explicit goals as to the nodes being registered as reachable in the DNS using the Ipv6 address - wherefore we are first and foremost looking to support the situation where communication is initiated by the tunnel clients and not from the outside. What do you think ? BR, Karen From owner-v6ops@ops.ietf.org Thu Sep 9 07:55:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10528 for ; Thu, 9 Sep 2004 07:55:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5NVR-000IR3-Mt for v6ops-data@psg.com; Thu, 09 Sep 2004 11:54:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5NV8-000INb-BC for v6ops@ops.ietf.org; Thu, 09 Sep 2004 11:54:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i89Brvt31907; Thu, 9 Sep 2004 14:53:57 +0300 Date: Thu, 9 Sep 2004 14:53:57 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: "'Radhakrishnan Suryanarayanan'" , , "'Soininen Jonne (Nokia-NET/Helsinki)'" , V6OPS WG Subject: RE: Comments on zeroconf draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > Normally last hops routers performs NUD so that they can send ICMPs > back to origin to notify of black holes/unreachability. Personally > I am not sure that this is a MUST requirement on the Tunnel Servers. > I have actually thought that we could avoid this, especially since > we have no explicit goals as to the nodes being registered as > reachable in the DNS using the Ipv6 address - wherefore we are first > and foremost looking to support the situation where communication is > initiated by the tunnel clients and not from the outside. This seems short-sighted to me, because the actual *advantage* of IPv6 is realized only when *incoming* connectivity is enabled (if it was just about outbound connectivity, v4 would work as well). If this would imply that the communication between two nodes inside the 3GPP network or communication originating from IPv6 internet and coming to a 3GPP node could just silently fail.. this would seem to be very undesirable. -- 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 Thu Sep 9 08:21:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12950 for ; Thu, 9 Sep 2004 08:21:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5Ntr-000Ld9-Al for v6ops-data@psg.com; Thu, 09 Sep 2004 12:19:39 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5NtA-000LYM-Fa for v6ops@ops.ietf.org; Thu, 09 Sep 2004 12:18:56 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3R00BGYWVJ4N@mailout1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 21:18:55 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3R006GCWM3US@mailout1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 21:13:15 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3R00JD2WM1MG@mmp1.samsung.com> for v6ops@ops.ietf.org; Thu, 09 Sep 2004 21:13:15 +0900 (KST) Date: Thu, 09 Sep 2004 17:42:47 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: Comments on zeroconf draft To: "Karen E. Nielsen (AH/TED)" Cc: V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <05d901c49666$52bfab20$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" ; "'Pekka Savola'" Cc: ; "'Soininen Jonne (Nokia-NET/Helsinki)'" ; "V6OPS WG" Sent: Thursday, September 09, 2004 3:26 PM Subject: RE: Comments on zeroconf draft > Hi Radhakrisnan, > > > > > > > Hi karen, > > I have some doubts. Can you clarify this point? > > The quote from the zerconf draft : > > " > > Tunnel state here is considered to be any parameter kept by the > > > > server per client and without which the server is unable > > to serve the > > > > client (receive packets from/send packets to). > > > > " > > Isnt the client's/end-node's v6address reachability using the v6-in-v4 > > tunnel itself a parameter maintained at the tunnel server? If so, then > > doesnt that itself means a tunnel state? > > > > If the mechanism is stateless, the v6 address of the clients need not be maintained > at the server. I think you know that - but I just want to be absolutely clear. > > Goal 6.8 is there first and foremost to allow for NUD like mechanism to be performed by the > tunnel clients so that they, if need arises, can ascertain the > reachability of their tunnel servers as > well as the reachability of peers in the direct tunnelling situation. > > I can see that this should be clarified in the draft. > > IF a Tunnel Server performs a NUD like mech on the clients it serves, > it must of course maintain reachability state as you describe. > > Normally last hops routers performs NUD so that they can send ICMPs > back to origin to notify of black holes/unreachability. > Personally I am not sure that this is a MUST requirement on the Tunnel Servers. I have > actually thought that we could avoid this, especially since we have no explicit > goals as to the nodes being registered as reachable in the DNS using the Ipv6 address - wherefore > we are first and foremost looking to support the situation where communication > is initiated by the tunnel clients and not from the outside. > > What do you think ? definitely i think we should think of communication initiation from both sides. > > BR, Karen > > From owner-v6ops@ops.ietf.org Thu Sep 9 08:42:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14675 for ; Thu, 9 Sep 2004 08:42:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5OE2-000Nvn-Ob for v6ops-data@psg.com; Thu, 09 Sep 2004 12:40:30 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5ODp-000NuA-Hm for v6ops@ops.ietf.org; Thu, 09 Sep 2004 12:40:18 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i89CeGlU025946 for ; Thu, 9 Sep 2004 14:40:16 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 14:40:16 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SNXMW1DY; Thu, 9 Sep 2004 14:40:15 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Sep 2004 14:40:15 +0200 Message-ID: X-Sybari-Trust: fd49a7b2 47b3073a 3037f7d6 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , V6OPS WG Cc: "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" Subject: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Thu, 9 Sep 2004 14:40:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Sep 2004 12:40:16.0187 (UTC) FILETIME=[2868C0B0:01C4966A] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Dear All, An issue of general character has been brought up in connection with the zero-conf work. The issue is the following: MUST Ipv6-in-Ipv4 tunnel servers, as routers, support NUD-like mechanisms that enables them to send ICMP destination unreachable messages back to origin ? The initial feedback received in this respect is that - "yes, they MUST". As some RFCs previously has been silent about this, e.g. 6to4 - RFC 3056, and the working group currently is standardising a mechanism which also seems to be silent about this (Teredo) I would very much like to hear if the above is the general sentiment of the work group. I should be stressed that adding this to the goals of the zero-conf requirements document isn't believed to severely limit the solution space - but it requires implementation of a mechanism which is know to scale very badly and which in addition is susceptible to the DoS attack described in Section 4.3.2 of RFC 3756. BR, Karen > > > On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > > Normally last hops routers performs NUD so that they can send ICMPs > > back to origin to notify of black holes/unreachability. Personally > > I am not sure that this is a MUST requirement on the Tunnel Servers. > > I have actually thought that we could avoid this, especially since > > we have no explicit goals as to the nodes being registered as > > reachable in the DNS using the Ipv6 address - wherefore we are first > > and foremost looking to support the situation where communication is > > initiated by the tunnel clients and not from the outside. > > This seems short-sighted to me, because the actual *advantage* of IPv6 > is realized only when *incoming* connectivity is enabled (if it was > just about outbound connectivity, v4 would work as well). If this > would imply that the communication between two nodes inside the 3GPP > network or communication originating from IPv6 internet and coming to > a 3GPP node could just silently fail.. this would seem to be very > undesirable. Note this is not about the connectivity silently failing, it is about the node no longer being there/no longer being active. But what you're saying is that the destination unreachable ICMPs are a MUST to support at a Ipv6-in-Ipv4 Tunnel Server ? - BTW, with the risk of bluring the difference in between solution space and requirement space - I suppose this in particular applies to the v6ops accepted "tunnel server" mechanisms, 6to4 and Teredo border routers ? > > -- > 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 Thu Sep 9 09:14:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17457 for ; Thu, 9 Sep 2004 09:14:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5OjS-0001zP-MN for v6ops-data@psg.com; Thu, 09 Sep 2004 13:12:58 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5OjH-0001xp-Gw for v6ops@ops.ietf.org; Thu, 09 Sep 2004 13:12:47 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 82A8280FA; Thu, 9 Sep 2004 15:12:43 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 14553-01; Thu, 9 Sep 2004 15:12:32 +0200 (CEST) Received: from [9.4.69.44] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D4AE17F68; Thu, 9 Sep 2004 15:12:30 +0200 (CEST) Subject: Re: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft From: Jeroen Massar To: "Karen E. Nielsen (AH/TED)" Cc: V6OPS WG In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TRloRomjzadhvSdtKrdQ" Organization: Unfix Message-Id: <1094735548.2119.26.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 09 Sep 2004 15:12:28 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-TRloRomjzadhvSdtKrdQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-09-09 at 14:40, Karen E. Nielsen (AH/TED) wrote: > Dear All, >=20 > An issue of general character has been brought up in connection with the = zero-conf work.=20 > The issue is the following: >=20 > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support NUD-like mechanisms= that enables > them to send ICMP destination unreachable messages back to origin ? >=20 > The initial feedback received in this respect is that - "yes, they MUST". >=20 > As some RFCs previously has been silent about this, e.g. 6to4 - RFC 3056, > and the working group currently is standardising a mechanism which also s= eems > to be silent about this (Teredo) I would very much like to hear if the ab= ove is the > general sentiment of the work group. What happens, afaik, is the following: Remote Box (A) =3D 2001:db8::1 tunnelendpoint @ Tunnel Server (Ts) =3D 2001:db8:1000::1 tunnelendpoint @ Tunnel Client (Tc) =3D 2001:db8:1000::1 R? =3D Routers in between. Thus schematically: A -> Ra -> Rb -> Rc -> Ts -(6in4/proto41 tunnel)-> Tc The packet will arrive at Ts, which will stick it into a 6in4 packet and actually forward it to Tc. Following situations could arise: a) IPv4 path works and Tc accepts the packet -> no problems b) IPv4 path works, Tc doesn't accept packet -> it should return with a proto-41 unreach icmp c) IPv4 route is broken between Ts and Tc -> it should return a unreach host In case of b and c when Ts gets a icmp route/port/host unreach they can send a IPv6 unreach route/host back to the Remote Box A. This is, what I noticed, is what the current Linux, KAME and XP implementations do. > I should be stressed that adding this to the goals of the zero-conf > requirements document isn't believed to severely limit the solution > space - but it requires implementation of a mechanism which is know to > scale very badly and which in addition is susceptible to the DoS > attack described in Section 4.3.2 of RFC 3756. The point where this can be DoS'd is by sending the Tc IPv4 unreachables for the Tc. Thus if you know the endpoints you can simply send a few icmp's and if the Ts remembers the state, which it hopefully does not do, then you can effectively disable the tunnel. The real way to fix this is doing egress/ingress filtering on IPv4... But many ISP's do not do any filtering at all, so tough luck. For that matter, the not so many IPv6 ISP's that are out there don't filter on IPv6 either, at least most of them, so most are repeating the same problem again, but all has to do with the router not being able to do filtering or something on linerate... Greets, Jeroen --=-TRloRomjzadhvSdtKrdQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBQFa8KaooUjM+fCMRAhvfAKCJPIvdp58uvbra3EBCNv3An5H9CQCeM7fE RF3m6/HjdhmtEfeNmBJ8DHE= =XM1n -----END PGP SIGNATURE----- --=-TRloRomjzadhvSdtKrdQ-- From owner-v6ops@ops.ietf.org Thu Sep 9 09:35:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18797 for ; Thu, 9 Sep 2004 09:35:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5P4D-0003pg-JI for v6ops-data@psg.com; Thu, 09 Sep 2004 13:34:25 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5P42-0003oU-Fv for v6ops@ops.ietf.org; Thu, 09 Sep 2004 13:34:14 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i89DY8lU008254 for ; Thu, 9 Sep 2004 15:34:13 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Sep 2004 15:34:08 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SMGS5PK4; Thu, 9 Sep 2004 15:34:08 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Sep 2004 15:34:08 +0200 Message-ID: X-Sybari-Trust: 925791e6 477d8de1 d8e0e1f9 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Jeroen Massar'" Cc: V6OPS WG Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Thu, 9 Sep 2004 15:34:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 09 Sep 2004 13:34:08.0061 (UTC) FILETIME=[AEC196D0:01C49671] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, > > Dear All, > > > > An issue of general character has been brought up in > connection with the zero-conf work. > > The issue is the following: > > > > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support > NUD-like mechanisms that enables > > them to send ICMP destination unreachable messages back to origin ? > > > > The initial feedback received in this respect is that - > "yes, they MUST". > > > > As some RFCs previously has been silent about this, e.g. > 6to4 - RFC 3056, > > and the working group currently is standardising a > mechanism which also seems > > to be silent about this (Teredo) I would very much like to > hear if the above is the > > general sentiment of the work group. > > What happens, afaik, is the following: > Remote Box (A) = 2001:db8::1 > tunnelendpoint @ Tunnel Server (Ts) = 2001:db8:1000::1 > tunnelendpoint @ Tunnel Client (Tc) = 2001:db8:1000::1 > R? = Routers in between. > > Thus schematically: > A -> Ra -> Rb -> Rc -> Ts -(6in4/proto41 tunnel)-> Tc > > The packet will arrive at Ts, which will stick it into a 6in4 > packet and > actually forward it to Tc. > > Following situations could arise: > a) IPv4 path works and Tc accepts the packet > -> no problems > b) IPv4 path works, Tc doesn't accept packet > -> it should return with a proto-41 unreach icmp > c) IPv4 route is broken between Ts and Tc > -> it should return a unreach host > > In case of b and c when Ts gets a icmp route/port/host > unreach they can > send a IPv6 unreach route/host back to the Remote Box A. > This is, what I noticed, is what the current Linux, KAME and XP > implementations do. > Thanks, So what you're saying is that the Tunnel Server can rely on the information from the IPv4 layer and thus does not need glue native IPv6 NUD-like mechanism on top of the IPv4 layer - ? > > I should be stressed that adding this to the goals of the zero-conf > > requirements document isn't believed to severely limit the solution > > space - but it requires implementation of a mechanism which > is know to > > scale very badly and which in addition is susceptible to the DoS > > attack described in Section 4.3.2 of RFC 3756. > > The point where this can be DoS'd is by sending the Tc IPv4 > unreachables > for the Tc. Thus if you know the endpoints you can simply send a few > icmp's and if the Ts remembers the state, which it hopefully does not > do, then you can effectively disable the tunnel. > > The real way to fix this is doing egress/ingress filtering on IPv4... > But many ISP's do not do any filtering at all, so tough luck. > For that matter, the not so many IPv6 ISP's that are out there don't > filter on IPv6 either, at least most of them, so most are > repeating the > same problem again, but all has to do with the router not > being able to > do filtering or something on linerate... > Neither of these are real problems in the particular scenario of zeroconf, due to its severe assumptions on IPv4 source filtering and source spoof preventions. A different issue however is that the server may be swamped with ICMP proto-41 unreachable from IPv4 nodes in the case where the server is used to reflect packets into the network. Thanks, Karen From owner-v6ops@ops.ietf.org Fri Sep 10 00:39:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06131 for ; Fri, 10 Sep 2004 00:39:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5d97-000LQQ-6o for v6ops-data@psg.com; Fri, 10 Sep 2004 04:36:25 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5d8t-000LP1-LT for v6ops@ops.ietf.org; Fri, 10 Sep 2004 04:36:11 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3T00CP6628E2@mailout1.samsung.com> for v6ops@ops.ietf.org; Fri, 10 Sep 2004 13:34:56 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3T0084G5WL2F@mailout1.samsung.com> for v6ops@ops.ietf.org; Fri, 10 Sep 2004 13:31:33 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3T00FT25WK78@mmp1.samsung.com> for v6ops@ops.ietf.org; Fri, 10 Sep 2004 13:31:33 +0900 (KST) Date: Fri, 10 Sep 2004 13:32:46 +0900 From: Soohong Daniel Park Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments onzeroconf draft In-reply-to: To: "Karen E. Nielsen (AH/TED)" , "'Pekka Savola'" , V6OPS WG Cc: "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support NUD-like > mechanisms that enables > them to send ICMP destination unreachable messages back to origin ? (Sorry if I am missing anything on this thread because I didn't fully follow up that so far.) When I saw this draft, below sentence was to cover the above concern. 6.8. Tunnel End-Point Reachability Detection The tunnel protocol must allow for means for one tunnel end-point to verify the reachability of other tunnel end-points towards which it intends to send packets. The unicast neighbor reachability discovery functions provided by IPv6 Neighbor Discovery ([13]), i.e., unicast NS/NA exchanges, should be supported on the tunnel link. NUD-like sounds good for me, however ICMP message exchange is not only available to verity a reachability between two endpoints. So don't limit this goal to the ICMP. When I implemented IPv6-over-IPv4 tunnel using DHCP, I used TCP/UDP port assigned by admin in advance between them, and it works well. Hope this helps. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. From owner-v6ops@ops.ietf.org Fri Sep 10 17:27:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10573 for ; Fri, 10 Sep 2004 17:27:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5srU-000Atd-Al for v6ops-data@psg.com; Fri, 10 Sep 2004 21:23:16 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5srI-000Arm-Lj for v6ops@ops.ietf.org; Fri, 10 Sep 2004 21:23:04 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 10 Sep 2004 14:24:38 -0700 X-BrightmailFiltered: true Received: from adahmed-w2k05.cisco.com ([64.101.173.79]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8ALN0Lq021700; Fri, 10 Sep 2004 14:23:01 -0700 (PDT) Message-Id: <4.3.2.7.2.20040910162104.017222b8@cactus> X-Sender: adahmed@cactus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Sep 2004 16:22:58 -0500 To: Brian E Carpenter From: Adeel Ahmed Subject: Re: I-D ACTION:draft-asadullah-v6ops-bb-deployment-scenarios-00.txt Cc: Ciprian Popoviciu , IPv6 Operations , patrick Grossetete In-Reply-To: <413823CE.40907@zurich.ibm.com> References: <4.3.2.7.2.20040901124020.018d0200@fruitpie.cisco.com> <200408191927.PAA27427@ietf.org> <200408191927.PAA27427@ietf.org> <4.3.2.7.2.20040901124020.018d0200@fruitpie.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [64.101.173.79] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello Brian, Please see my comments in line: At 09:57 AM 9/3/2004 +0200, Brian E Carpenter wrote: >Just one follow up: > >>>6) Section 7.5 >>> >>>> The NAP can stop IPv6 traffic from customer that did not subscribe to >>>> the service by using layer two filters based on the IPv6 Ethertype >>>> (0X86DD). >>> >>> >>>I think this is irrelevant - it isn't related to a security threat. It's >>>also getting into business model territory, which we try to >>>avoid in the IETF. >> >>@@@ >>In a bridged network, wouldn't this be useful as a means for an access >>provider to >>keep its network IPv6 free if it so decides? >>@@@ > >Well yes, but equally if it wants to keep its network free of Novell IPX or >Appletalk over Ethernet or any other Ethertype. I really don't see why >the IETF should advise providers how to *block* IPv6 specifically. This is >a document about how to support IPv6. Maybe you should turn it round: > > If any layer two filters for Ethertypes are in place, the NAP must > permit the IPv6 Ethertype (0X86DD). That's a very good point. We will make this change in the next revision of the draft. Thanks for all your help ! Kind Regards, Adeel. > Brian > > >Ciprian Popoviciu wrote: >>Brian, >>Thank you for your comments and suggestions. Please find in line our >>answers, clarifications and questions. We are looking forward to your >>response and suggestions. >>Regards, >>Chip >>At 05:10 PM 8/26/2004 +0200, Brian E Carpenter wrote: >> >>>Just a few quick comments on this very long document, which I >>>think fills a need (though whether it should be an RFC, or >>>expanded into a book, I'm not quite sure). >>> >>>1) I think I disagree with one comment Pekka made, about the >>>same material being repeated in several sections. I think each of the >>>major sections should be complete in itself, to avoid complex cross- >>>references. >>> >>>2) Here's a comment that I think applies to all four scenarios described. >>>The case of subscribers that get more than a /64, actually a /48 if >>>RFC 3177 is followed, is not described, unless I missed it. This may only >>>apply to a minority of subscribers initially, but it must certainly >>>be covered. >> >>@@@ >>We touched on this subject partially when mentioning the use of DHCP-PD >>used to assign /48 to customer premises routers. We are planning to >>add more information on this topic so this comment will be integrated >>in the next iteration. >>@@@ >> >>>3) Just an observation: the document implies in all scenarios that GWR >>>vendors will update their products to be fully dual stacked. I can only >>>agree that is highly desirable, but you are asking for quite a lot. >> >>@@@ >>This is true but our intent was to look forward to large scale deployments >>where IPv6 is more then a service. We argued that the user can simply get >>connectivity through dual stack PCs that talk to the SP edge access equipment >>however, on the long run the users and providers will drive the CPE >>manufacturers >>to get the GWR ready for dual stack use. >>@@@ >> >>>4) Section 5.2.2.1.3 >>> >>>>5.2.2.1.3 Data Forwarding >>>> >>>> All IPv6 traffic will be sent to/from the ER and the host device. >>>> In order to transport IPv6 packets over the cable operator's >>>> IPv4 network, the host and the ER will need to use tunneling >>>> mechanisms such as 6to4 tunneling [RFC 3056]. >>>> >>>> The host will use its global IPv4 address to source the tunnel to >>>> the ER. >>> >>> >>>So, as Pekka also pointed out I think, you are assuming global IPv4 >>>addresses at this level. What about countries that are already running >>>multiple levels of NAT in order to reach local ISPs? 6to4 is broken in >>>that case. Also, you don't explain how the 6to4 relay is discovered - >>>do you assume the anycast trick is used (RFC 3068)? And incidentally it >>>means that all such hosts will have 6to4 prefixes, so baroque routing >>>is likely. 6to4 was designed to *bypass* local ISPs without IPv6 support, >>>not to *help* them. >> >>@@@ >>Our intent was to describe non-tunnel based deployments but rather >>deployments similar >>to the IPv4 ones. The cable access case study is special because of the >>current >>state of DOCSIS. This is the reason why tunnels were used here. That being >>said, based on the comments we received, it is clear that we need to >>expand a bit >>more on the topic and provide some clarifications. We will make some >>additions and >>keep in mind the point raised by this comment. >>@@@ >> >>>5) Section 5.2.2.2 >>> >>>> The cable operator can provide IPv6 services to its customers, >>>> in this scenario, by adding a GWR behind the CM. Since the GWR >>>> will facilitate all IPv6 traffic to/from the host and the ER, the >>>> cable network including the CM and CMTS do not need to support IPv6 >>>> and can remain IPv4 devices. >>> >>> >>>But this also has to work when the subscriber goes to the local >>>electronics store and buys $99 Wireless Access Gateway, without the >>>cable operator lifting a finger. Incidentally, in this case, if >>>you use 6to4, the GWR will have to be a full RFC 3056 6to4 router, >>>but the hosts behind the GWR don't need to know anything about 6to4. >> >>@@@ >>True, this falls a bit in the topic of who owns the GWR. Yes, having the >>GWR do >>the 6to4 tunneling is one of the ways to deal with having a single globally >>routable IPv4 address that might be used with NAT for existent v4 >>connectivity. >>We will elaborate on the topic since it was brought up in other feedback >>we received. >>@@@ >> >>>6) Section 7.5 >>> >>>> The NAP can stop IPv6 traffic from customer that did not subscribe >>>> to the service by using layer two filters based on the IPv6 >>>> Ethertype (0X86DD). >>> >>> >>>I think this is irrelevant - it isn't related to a security threat. It's >>>also getting into business model territory, which we try to >>>avoid in the IETF. >> >>@@@ >>In a bridged network, wouldn't this be useful as a means for an access >>provider to >>keep its network IPv6 free if it so decides? >>@@@ >> >>>7) Section 10, References >>> >>>You mention RFC 3056 in the text, but it isn't listed. Also, as noted above, >>>do you also need a reference to RFC 3068? >> >>@@@ >>Noted, we will make the necessary corrections. >>@@@ >> >>> Brian >>> >>>Internet-Drafts@ietf.org wrote: >>> >>>>A New Internet-Draft is available from the on-line Internet-Drafts >>>>directories. >>>> >>>> Title : ISP IPv6 Deployment Scenarios in Broadband >>>> Access Networks >>>> Author(s) : S. Asadullah, et al. >>>> Filename : >>>> draft-asadullah-v6ops-bb-deployment-scenarios-00.txt >>>> Pages : 0 >>>> Date : 2004-8-18 >>>> >>>>This document provides detailed description of IPv6 deployment and >>>>integration methods and scenarios in today's Service Provider (SP) >>>>Broadband (BB) networks in coexistance with deployed IPv4 services. >>>> Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB >>>> technologies that are currently deployed, and discussed in this >>>> draft. In this document we will discuss main components of IPv6 BB >>>> networks and their differences from IPv4 BB networks and how IPv6 >>>> is deployed and integrated in each of these BB technologies. >>>>A URL for this Internet-Draft is: >>>>http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-00.txt >>>> >> From owner-v6ops@ops.ietf.org Fri Sep 10 19:01:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17982 for ; Fri, 10 Sep 2004 19:01:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C5uNc-000MyS-UO for v6ops-data@psg.com; Fri, 10 Sep 2004 23:00:32 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C5uNR-000Mx7-Dw for v6ops@ops.ietf.org; Fri, 10 Sep 2004 23:00:21 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 10 Sep 2004 16:00:54 -0700 X-BrightmailFiltered: true Received: from adahmed-w2k05.cisco.com ([64.101.173.79]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8AN0Hxl026624; Fri, 10 Sep 2004 16:00:18 -0700 (PDT) Message-Id: <4.3.2.7.2.20040910170906.0173e1e8@cactus> X-Sender: adahmed@cactus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Sep 2004 18:00:17 -0500 To: Pekka Savola From: Adeel Ahmed Subject: Re: Draft on ISP broad-band deployment scenarios Cc: Ciprian Popoviciu , v6ops@ops.ietf.org, Adeel Ahmed , Salman Asadullah , Patrick Grossetete In-Reply-To: References: <4.3.2.7.2.20040831213539.018e7e80@fruitpie.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [64.101.173.79] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello Pekka, Please see my responses inline with +++++++++++++++: At 02:43 PM 9/7/2004 +0300, Pekka Savola wrote: >Sorry for the delay in responding.. inline... > >(I've removed some comments which we seemed to agree or be clear >about.) > >On Wed, 1 Sep 2004, Ciprian Popoviciu wrote: > > >On Thu, 19 Aug 2004, Pekka Savola wrote: > > > > Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a > > > > lot of work in a very short time and produced a really extensive > > > > scenarios document discussing the IPv6 deployment scenarios for > > > > broadband (DSL, cable, etc.). > > > > > >A couple of general observations: > > > > > > 0) is the document aiming to only describe the scenarios, or is the > > >goal to also provide analysis where potential gaps have been > > >identified, and where e.g., a tunneling mechanism would be needed? If > > >the latter, it probably needs to be expanded a bit. > > > > @@@ > > Pekka, to put this document in perspective, here are some elements of our > > original intent: > > - focus on production type deployments. We did not intend to discuss > tunneling > > unless it is the only alternative currently available due to > limitations of > > a given access > > technology (cable). > >OK, though I'm not sure how certain types of tunneling solutions could >not be considered "production" (or sufficiently near that) to be >useful on a larger scale. The justification for that is that there >may be lots of equipment that is not IPv6-capable, and having to wait >for it to be replaced to be able to offer (or get) IPv6 connectivity >may be a big assumption for deployment. +++++++++++++++ Our goal in this draft is to get SPs to move towards deployment of native IPv6. So leading to such deployments tunneling would be a stepping stone for the SPs. However, considering that there are native deployments today, we wanted to focus more on them rather then on the transitional phase in which it might be rather difficult for an SP to generate revenue from a tunnel based service till they move towards native IPv6 deployments. In the case of Cable (section 5) we had to talk about tunnels due to the current limitations in DOCSIS but all the other access technologies discussed in the draft are ready for native IPv6 deployment today. +++++++++++++++ > > - present the possible deployment scenarios and identify the major elements > > for each one in terms of enabling IPv6 services. > > - highlight changes that have to be made in the deployment process and some > > issues that the SP has to keep in mind while planning such a deployment. > > > > As you can see, the document is rather large as it is so we did not > consider > > going into more detail then we already did. We did want however to > underline > > topics that should be kept in mind during deployment, even items that > should be > > further investigated. We believe that this approach is what you > mentioned above > > but maybe we need to highlight more some aspects of the document. Could > you > > clarify > > your comment above so that we make sure we properly understand the > changes you > > suggest? We would like to make this work as useful as possible. > > @@@ > >This is partially clarified later in this message, esp. point 1) >below. > >The question I was asking was whether you intended to analyze the >applicability of different methods for getting IPv6 connectivity (in >case there would be multiple: for example, where you cite 6to4, there >could very likely be others as well, possibly even more suitable than >that), or just pick one (or none) and describe how that would work. >In other words, I was interested whether you were considering >"generic" deployment (with as few assumptions as reasonable, about, >e.g., equipment at the customer's premises), or "specific" deployment >(where you could or could not assume some things, like being able to >upgrade a certain box or having public IPv4 addresses). > >The document would certainly seem to be most useful if it was >sufficiently "generic", but a "specific" document is also better than >nothing ;-), provided that the assumptions are very clearly spelled >out. +++++++++++++++ We've actually tried to be specific in sections 6,7 & 8. We've used kind of a generic approach in section 5 due to the current state of cable networks and the limitations in DOCSIS. We will try to spell out some of the assumptions more clearly in our next revision of the draft. +++++++++++++++ > > > 1) the doc seems to be lacking large-scale v6 enablement > > >considerations, w/o customer interaction and manual config. That is, > > >at least in section 5, I got the impression that for the customer to > > >enable v6 over a tunnel, the customer and the ISP would have to do > > >some manual configuration. This seems unscalable and unfeasible. > > >Shouldn't we try to have mechanisms where the nodes automatically > > >detect if IPv6 is available through a tunnel, and activate it if so? > > > > @@@ > > This is a good point that we should elaborate on. It is also true that > > while in some cases simple provisioning is available (use of autoconfig or > > DHCP-PD) in others there might not be a solution available today. In such > > cases, > > based on your comment above, it looks like you would like to see us clearly > > identify such limitations and possibly open the door for further work. > Is this > > correct? > >Yes -- I don't see it as a problem that a document idenitifies gaps or >room for further work. That's good, because at least some folks >already have their own view on what's needed, and by writing it down >we can discuss and get (hopefully!) agreement on what's needed. > >Note that there has already been work in progress in some of these >areas (see, for example, >http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-01.txt). > > > > 2) the document seems to make some assumptions e.g., when it > specifies to > > >use 6to4 e.g., for cable. Are all of the networks using public v4 > > >addresses? What if the customer has deployed a NAT box so that the public > > >address is consumed by that box? Further, I'm not sure whether the > > >situation where the customer has deployed some equipment has been > considered > > >throughout the document. > > > > @@@ > > Again, it is a case very specific to the current state of Cable > > access. > >Do you mean that cable operators are widely offering a public IP >address per customer? However, I'd venture to guess there are a >significant number of operators which only give private addresses to >begin with. +++++++++++++++ Actually that is a common practice with most Cable Operators. We've worked with major Cable providers in the America, EMEA and APAC regions and they all offer public IP addresses to their customers. +++++++++++++++ > > Nevertheless we could probably offer more detail for this > > case. For example, one solution would be to have the box that is > > doing the NAT for the user also terminate the tunnel. > > > > This is another point that we need to clarify however, the Gateway > > Router (GWR) can be SP owned but also it can be customer owned and > > in that case it would reflect a customer deployed equipment like a > > box that does NAT for v4. > > @@@ > >Exactly, this cuts both ways: one approach could be to assume that the >NAT box (which may be beyond the control of the SP) is upgraded -- >this could take quite a long time to achieve. Another approach could >be to provide mechanisms which work irrespective of NATs -- there are >already a plenty of those, for example Teredo, and some others >probably to come (think of "configured tunneling over UDP with >keepalives"), in one form or the other. > >I think what you were assuming that you only need to care about the >case of upgrading the NAT box. That may be acceptable with certain >assumptions about the deployment (if that's the case, they must be >very clearly spelled out), but it may not be sufficient in more >general -- so if you agree that one would want to provide v6 access >also when there are NATs or other obstacles in the way, one such >approach is to specify v6 connectivity mechanissm which work through a >NAT. > +++++++++++++++ That's a good point, we will make a note of that in section 5 where we discuss initiating a tunnel from the host. Since our goal is to provide IPv6 access natively this should not be an issue for other technologies. +++++++++++++++ > > > 3) there's duplicated text in very many of the sections which applies > > >to about all the scenarios, for example: > > > > > > Depending on the design of the edge portion of the ISP network, some > > > Edge Routers might have to run iBGP for IPv6. In this case it is > > > expected that two peer sessions are established between the Edge > > > Router and a pair of redundant Route Reflectors. > > > > > >.. instead of duplication, would there be a good logical place to put > > >all the "generic considerations" wrt. access networks (e.g., about > > >prefix summarization, etc.) into a dedicated section? -- And just > > >describe the access-network -specific issues under the access > > >network.. that might remove duplicate text and make the document more > > >concise. > > > > > >This might force the reader to think about the generic issue and how they > > >map to the specific access network scenario a bit more, but it would > > >probably improve the readability and correctness. > > > > > >The tradeoff of course is that each access network description would no > > >longer be readable on its own without reading the rest, but that should > > >probably be acceptable ... as it is, there seems to be significant overlap > > >with the sections, especially with DSL, Ethernet, and WLAN, but a bit > > >otherwise as well. > > > > > >If that was done, it might be possible to push down from 60 pages to > > >20-30 pages, and even increase the amount of unique content in the > > >process. > > > > @@@ > > Before writing the document we actually discussed this topic amongst > > ourselves. Our thought is that some items might seem similar between > > sections but they might not be in all their details. Moreover, we > > did want to provide each Access Technology section a certain > > completeness and independence in order to make the sections more > > readable, without having to send the reader very far through > > referencing. Even if we were to compress the repeated subsections we > > doubt that the document will shrink to only 30 pages. We received > > pro and con arguments on this topic so for now we would like to keep > > it in this format as it might even be easier to further flesh out > > some sections based on the feedback received. As the document > > evolves we can revisit the formatting if it proves advantageous. > > @@@ > >Would there be some kind of middle-path, e.g., a section describing >more generic considerations which are actually common to all the >access networks (or close enough)? I'm a bit afraid of the scenario >where we'd have to include identical text in 5 different sections if >we figured out we needed to add some common text :) > >But if you believe this is sufficient at this point, I can live with >it. I've just seen (in the past) a lot of work getting spent in >keeping the text in sync, and I wanted to avoid that if possible. +++++++++++++++ Your point is well taken. For now we would like to keep the format as it is to maintain consistency among different sections. We can revisit this issue in the future. +++++++++++++++ > > >==> actually, the current recommendation (RFC 3177) is even larger: a /48 > > >per home :-). This should probably be mentioned.. > > > > @@@ > > True. We sort of touched on that with our DHCP-PD recommendations. There > > are also > > SPs that might assign prefixes between /48 and /64 with the intent of > charging > > for address space. > > @@@ > >Yes, seems inevitable -- but let's just hope they'd still give at >least /64 or something like that, instead of /128's. > > > > 2. IPv4 Cable (HFC) Network, GWR at customer site > > > > > > In this case the cable network, including the CM and CMTS remain > > > IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This > > > scenario is also easy to deploy since the cable operator just needs > > > to add GWR at the customer's site. > > > > > >==> is this necessarily this simple? What is the cable operator > already has > > >deployed v4-only GWR for other purposes? Does it need to be upgraded to > > >dual-stack? Or what if the user has added a box of its own, e.g., a > > >firewall/NAT/wireless router? I guess it again needs to be upgraded. > > > > @@@ > > These are deployment issues that we could elaborate a bit more on. The > > provider usually > > is not responsible for the additional equipment added by the customer and > > under the > > constraints of a service deployment that is limited by the current > state of > > DOCSIS it is likely that > > the provider will have to provide a new device to the subscriber. We will > > add a note on this > > topic. > > @@@ > >This is one approach, as noted at the start of the message; another is >providing tunneling support. Both could be feasible, depending on >deployment, but the latter is more generic at least. +++++++++++++++ Right, so cable operators currently do provide a GWR which is managed by them. In order to deploy IPv6 the operator can upgrade or replace this GWR with a v6 capable device. +++++++++++++++ > > >5.2.2.2.4 Routing > > > > > > > > > For 6to4 tunneling,a static 2002::/16 route and a default IPv6 route > > > can be manually configured on the GWR with the IPv6 address of the ER > > > as the next hop. A similar IPv6 route will need to be configured on > > > the ER pointing back to the GWR at customer site. > > > > > >==> does that require manual configuration at ER for each customer? > > >Hopefully not! (AFAICS, there's nothing needed for 6to4, but manual > > >tunneling would need it.) > > > > @@@ > > We will discuss provisioning in more detail and hopefully this question > > will be answered in > > that context. It is worthwhile to note that we don't advocate the use of a > > specific tunneling > > mechanism for this temporary solution for Cable Networks. We will more > > clearly identify > > items to be considered when making the selection for the tunnel but the > > selection will > > be left to the person planning the deployment. > > @@@ > >OK -- Analyzing the different mechanisms is fine. However, if it >requires IETF specification, there must be some document that makes >the decision what needs to be specified (if not everything). It >doesn't need to be in this doc, though. (This was my point zero at >the start of the message -- whether this doc was intended to >include analysis, and if so, how much of it...) +++++++++++++++ We do understand your point. We will try to address this in our next revision of the draft. +++++++++++++++ > > > If using maunual tunneling, the GWR and ER can use static routing or > > > they can also configure RIP-ng. The RIP-ng updates can be transported > > > over a manual tunnel, which does not work when using 6to4 tunneling. > > > > > >==> is there a particular usage case for RIP-ng over cable modem to > the GWR? > > >I can't see any valid scenario for doing so.... > > > > @@@ > > This is a valid point. We need to provide more context to the statement, > > but it is worthwhile > > to note that it is a current practice in IPV4 networks where business > > customer do run RIPv2 > > between the CM/GWR and the CMTS. Those customer routes are > redistributed in > > the ISP's IGP. > > @@@ > >OK -- I'm just having trouble visualizing any ISP doing so, because >that might directly jeopardize their IGP to the customers.. and I'd be >interested in hearing why they would be doing something like this (is >this some kind of backup routing plan for some SOHO customers or the >like or what). +++++++++++++++ This is currently a normal practice for Cable Operator's business customers. There are only a handful of these customer routes which are summarized and redistributed into the Cable Operator's IGP. This is not really meant for residential customers which account for majority of the customer base. +++++++++++++++ > > > The CMTS/ER should protect the ISP network and the other subscribers > > > against attacks by one of its own customers. For this reason uRPF and > > > ACLs should be used on all interfaces facing subscribers. Filtering > > > should be implemented with regard for the operational requirements of > > > IPv6 (ICMPv6 types). > > > > > >==> I don't understand what you mean by the last sentence? > > > > @@@ > > We probably used too few words. We wanted to say that while configuring > IPv6 > > ACLs, one has to make sure that the ACLs do not stop IPv6 specific controll > > plane traffic (like ND, DHCP-PD etc). > > @@@ > >I'd hope that folks wouldn't filter ICMPv6 at all, but that's probably >too much to hope for.. remember, you cannot use e.g., 'ping' for host >scanning purposes as you have about 2^64 potential hosts in a >subnet... > > > > In IPv6, with [RFC3306] there is a better mechanism available for ASM > > > IPv6 address allocation than in IPv4. This reduces the problems of > > > using ASM in IPv6 to some degree. On the other hand, the protocol MSDP > > > standard with PIM-SM is not currently defined for IPv6. In general, > > > SSM for IPv6 is also considered to be the protocol to promote for the > > > majority of future interdomain IP multicast applications and it is > > > less complex solution to operate. > > > > > >==> you might want to check out and refer to > > >draft-ietf-mboned-ipv6-multicast-issues-00.txt which discusses exactly > this > > >issue, and solutions if you'd still need ASM. > > > > @@@ > > Yes, we are aware of this work and we will reference it. We didn't really > > want to get into a model other then SSM despite the fact that there are > > feasible > > ways for ASM. The idea was that SPs will be more inclined to go for an SSM > > model > > at first (maybe even on a longer run) because of the business model of > content > > delivery (video/audio). Probably we should however have a discussion on > the > > topic. > > Do you see the ASM discussion important beyond referencing the draft you > > mentioned? > > @@@ > >Well, ASM is what's used (or actually, not being widely used :) today, >so it's a bit surprising to see it waved off just like that.. I guess >it would be OK to mention ASM more briefly, and refer to possible >solutions, but concentrate on SSM (and state the reasons for doing so, >i.e., the easier business model for content delivery). +++++++++++++++ Sure, we can do that in the next revision of the draft. +++++++++++++++ > > >6.2.1 POINT-TO-POINT MODEL > > > > > > > > >==> this model has the built-in assumption that ATM is used as > > >point-to-point. Is this strictly necessary, or could you just use any > other > > >media as well? > > > > @@@ > > Could you please clarify this comment? > > @@@ > >I meant that wouldn't it be possible to use e.g., Ethernet (instead of >ATM) as the point-to-point uplink? I haven't seen this myself, but >I've heard reports of such deployments.. +++++++++++++++ We've discussed this in the FTTH section 7.2.1. So we did not really assume that only ATM will be used as a point-to-point uplink. +++++++++++++++ > > > If a Customer Router is present: > > > > > >[...] > > > - it dynamically acquires through autoconfiguration the address > for the > > > link between itself and the Edge Router. This step is followed by a > > > DHCP-PD [RFC 3633] request for a prefix shorter then /64 that in > turn is > > > divided in /64s and assigned to its interfaces connecting the hosts on > > > the customer site. > > > > > >==> s/present/present, either:/ > > > > > >==> the router doesn't autoconfigure the address unless it has been > > >configured to act as a host on its upstream interface... which would > > >probably be bad practice.. so either the upstream link has no global > > >addresses (which would be OK), or it could just use a subnet from the > > >DHCP-PD prefix. > > > > @@@ > > Why would you see it as a bad practice having the router acquire via > stateless > > autoconfig an address for the uplink to the provider? We should probably > > discuss > > all options for completeness purposes. > > @@@ > >Well, if you have a router, I'd generally expect it to act as a router >on all of its interfaces. There has been some debate of this mixed >"host/router" behaviour on IPv6 WG list before, but I think the >conclusion has been that mixed host/router is acceptable by the specs >at least. I'd however personally rather see that the routers in these >situations would have other means to configure an address (if they >need one). +++++++++++++++ We've seen customer interest in using this approach for IPv6 therefore we discuss it in the draft. Similar approach is also available in IPv4. +++++++++++++++ > > > MLD authentication, authorization and accounting is usually > > > configured on the edge router in order to enable the ISP to do > > > controll the subbscriber access of the service and do billing for > > > the content provided. > > > > > >==> the non-standardized methods for adding AAA to IGMP/MLD have been > > >proposed, but they're generally considered very broken models, and I'm not > > >sure how much text we should have about them, at least without > disclaimers. > > >The right thing to do would probably be to encrypt the data, and > provide the > > >decryption key only to those who pay (or whatever for the stream. > > > > @@@ > > We believe that such a feature is important to all SPs that deploy > > mcast services for video and audio streaming. Maybe this is not > > critical at the start of the service but would be when the service > > offering solidifies. Such a feature offers more granularity in > > controlling and charging a customer then the key proposal. With the > > key proposal the user would have access to possibly a predefined > > package of channels while with proper MLD AAA the user can select > > any channel, any time and be charged only for that use. > > @@@ > >These arguments should maybe go in the draft, but still keep in mind >that MLD/IGMP have not been meant to authenticate the users. > >I'd expect that the same features can be obtained with encrypted data. >You would get the key which would be valid only for some time from a >web server, and that key would be only valid for a certain stream. >That way you could get the keys etc. only only those parts of the >transmission you'd want. There are possibly other approaches. MSEC >(http://www.ietf.org/html.charters/msec-charter.html) WG has been >looking at this problem. +++++++++++++++ We do realize that there are multiple ways of doing this but we went with MLD authentication approach because we have seen requirements for this from customers and it's a rather simple approach. But we will try to add more explanation in the next revision of the draft. +++++++++++++++ Kind Regards, Adeel Ahmed. >-- >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 Sun Sep 12 09:56:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15672 for ; Sun, 12 Sep 2004 09:56:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C6UmY-000LKz-CZ for v6ops-data@psg.com; Sun, 12 Sep 2004 13:52:42 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C6UmM-000LIS-HK for v6ops@ops.ietf.org; Sun, 12 Sep 2004 13:52:31 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000418733.msg for ; Sun, 12 Sep 2004 15:56:31 +0200 Message-ID: <229e01c498cf$b2d8ee70$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Comments on zeroconf draft Date: Sun, 12 Sep 2004 15:49:04 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sun, 12 Sep 2004 15:56:31 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Sun, 12 Sep 2004 15:56:32 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, all, See my response in-line, below. Regards, Jordi ---- Original Message ---- From: "Pekka Savola" To: "Karen E. Nielsen (AH/TED)" Cc: "'Radhakrishnan Suryanarayanan'" ; ; "V6OPS WG" Sent: Wednesday, September 08, 2004 1:14 PM Subject: RE: Comments on zeroconf draft > My personal opinions only. >=20 > On Wed, 8 Sep 2004, Karen E. Nielsen (AH/TED) wrote: >> Apart from this as i had already mentioned in my previous mails >> about a thought of expanding the applicability of this document >> beyond 3GPP. Maybe this is for the WG chair to decide. >>=20 >> [Karen E. Nielsen (AH/TED)] Thanks for your comments in that respect >> also. [...]=20 >>=20 >> Now given that we have the requirements, this document could be used >> to decide: >>=20 >> * Initial: whether the 3GPP case is sufficiently different from >> assisted tunnelling for it to have its on life requirements wise >=20 > I'd say, no, "zeroconf" requirements are common enough; some are > 3GPP-specific, but many are not. Then a logical approach would seem > to be have a "generic requirements" section (which would still be > sufficiently grounded in the operational scenarios), and sections on > specific requirements under different scenarios. I've a similar view. I think it will be very useful to, once we have finalized the actual 3GPP specific requirements, complement or even rearrange the document in such way that we describe what of those requirements fit also in other scenarios (not just 3GPP). But we need to understand, as already explained before, that the main goal of the document is 3GPP. I mean, once 3GPP is done, now is more and more clear for all that it also provides a good set for a simple solution that could fit very well in other situations. >=20 >> (and solution wise) - (if not the timing requirements alone makes it >> necessary for it to have its own life). >=20 > IMHO, as this is just the requirements, the solutions could be the > same or not if everything was done under the label of "zeroconf", so I > don't see this as a big factor. >=20 >> * Subsequently: if zeroconf tunneling as a concept is granted its >> own life, are there additional scenarios where this may be >> applicable. >>=20 >> Further are the additional requirements that should be served by >> zeroconf tunnelling so that it will be applicable to additional >> scenarios, which do not fit within the framework of assisted >> tunnelling. >=20 > IMHO, yes. >=20 > I can't see additional requirements which weren't there under the > assisted tunneling. >=20 > Remember that assisted tunneling went out to provide requirements for > two different cases: "zero-conf -like", and "controlled". Now that > there is draft out on "zero-conf -like", it doesn't seem to be useful > to cover that under assisted tunneling, but just make it cover > "controlled". Overlap won't do us any good.. This is a very good point. Actually zero-conf looks for a simple solution, which probably means not-controlled (assumed to be "self-controlled" because only works for the own-network-customers, read own-network as the ISP network, 3GPP network, enterprise network, etc.). ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Sep 12 12:59:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27117 for ; Sun, 12 Sep 2004 12:59:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C6XeE-000EQp-CX for v6ops-data@psg.com; Sun, 12 Sep 2004 16:56:18 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C6Xe3-000EMT-5k for v6ops@ops.ietf.org; Sun, 12 Sep 2004 16:56:07 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000418881.msg for ; Sun, 12 Sep 2004 19:00:12 +0200 Message-ID: <232f01c498e9$5eac5250$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: IPv6 Tunnel End-point Automatic Discovery Mechanism Date: Sun, 12 Sep 2004 18:55:53 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sun, 12 Sep 2004 19:00:12 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-MDAV-Processed: consulintel.es, Sun, 12 Sep 2004 19:00:13 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Daniel, Thanks for your comments. Please see my inputs in-line below. Regards, Jordi ---- Original Message ---- From: "S. Daniel Park" To: "JORDI PALET MARTINEZ" ; Sent: Tuesday, September 07, 2004 9:55 AM Subject: RE: IPv6 Tunnel End-point Automatic Discovery Mechanism > Hi Jordi, thanks your effort on this work. >=20 > Basically, you have to use a new boilerplate for this draft. I'm surprised. I though that using the HTML interface of http://xml.resource.org/ the boilerplate is automatically added (the good one). May be I published the I-D right before a change ? > In this draft, several abbreviations (i.e., TEP, TS, TEB...) > are shown without any terminology description, so I > recommend you to simply address them if possible. Yes, you're right, a terminology section will be very useful. >=20 > My major comment is as below; >=20 > In Abstract; >=20 >> This memo proposes a solution for discovering the IPv6 TEP >> in a simple an efficient way. >=20 > Isn't the IPv4 TEP correct ? (if you mean tunnel described in > this draft is the IPv6-over-IPv4 tunnel). IPv6-over-IPv4 tunnel where > the IPv4 tunnel endpoint address is learned from the solutions > proposed in this draft. If you mean IPv6 TEP is only *endpoint* > from the IPv6 aspect, you should at lease address this assumption > and indicate the difference between TEP and TEP address. > For example: TEP address is a destination address of IPv4 > encapsulating IPv6 packets where IPv6-over-IPv4 tunnel is the > technique of encapsulating IPv6 packets within IPv4 is used > to accross IPv4 routing infrastructures. I'm meaning in general any type of tunneling mechanism that uses 6in4 (proto-41), to encapsulate IPv6 in IPv4. My view is that as we are tunneling IPv6, the tunnel end point is an IPv4 address, so then you're probably right, it should be IPv4 TEP. We can clarify this in the next version. But actually, in the conclusions section, we have an open question mark: Can/should we use this document also for auto-discovering IPv4 in IPv6 tunnels ? My belief is that this mechanism is equally applicable to discover the TEP for the reverse situation, when we need to create a 4in6 tunnel. If is the case and this is acceptable for the WG, then we need to review all the references to TEP across the text, and replace A/CNAME with A/AAAA/CNAME, etc. My personal opinion is that this will provide a very efficient way to open the path for the next stage of the transition, using the same mechanism, instead of defining something different. It just doesn't make any sense. But I need to spend some time in looking if for example SRV and anycast will work the same. I will much prefer to get first feedback from the WG about if this mechanism of doing the discovery is acceptable, etc. >=20 >=20 > Thanks >=20 >=20 > - Daniel (Soohong Daniel Park) > - Mobile Platform Lab. Samsung Electronics. >=20 >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org]On Behalf Of JORDI PALET MARTINEZ >> Sent: Monday, September 06, 2004 11:24 AM >> To: v6ops@ops.ietf.org >> Subject: IPv6 Tunnel End-point Automatic Discovery Mechanism >>=20 >>=20 >> Hi, >>=20 >> We have submitted a new document. It can be already read at: >>=20 >> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-solution >> -tun-auto-disc-00.txt >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >> ********************************** >> Madrid 2003 Global IPv6 Summit >> Presentations and videos on line at: >> http://www.ipv6-es.com >>=20 >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the use of the individual(s) named above. If you are not the >> intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, >> including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Sep 13 02:43:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29662 for ; Mon, 13 Sep 2004 02:43:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C6kVM-000IyK-JW for v6ops-data@psg.com; Mon, 13 Sep 2004 06:40:00 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C6kV3-000IwE-6s for v6ops@ops.ietf.org; Mon, 13 Sep 2004 06:39:41 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id E404A800D for ; Mon, 13 Sep 2004 08:39:33 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 10615-55 for ; Mon, 13 Sep 2004 08:39:25 +0200 (CEST) Received: from [9.4.69.44] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D65BC7F68 for ; Mon, 13 Sep 2004 08:39:23 +0200 (CEST) Subject: Which IPv6 Option Types are reserved for testing? From: Jeroen Massar To: v6ops@ops.ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rCS4uddCO/ctLqScqRnR" Organization: Unfix Message-Id: <1095057557.2608.283.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 13 Sep 2004 08:39:18 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-rCS4uddCO/ctLqScqRnR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I am currently extending AYIYA to do proper multihoming. As I intend to do wider-scale testing, outside of the very small test setup I am currently using, I was wondering what Option Types are reserved or can be used for this kind of testing. Because, just like the 206 ICMPv6 option for MLDv2, changing it after it has been circulated quite a bit can be a bit painful, indeed it is a part of the kernel. Reading: http://www.iana.org/assignments/ipv6-parameters It apparently contains no reserved ones. Typically it would need a: act chg rest --- --- ----- 11 0 xxxxx AYIYA Option Header But what can I use for the last 5 bits? Exact contents of this header will come in the next update, -03 version of the AYIYA draft, which will also describe how it is used and=20 I could of course fill in a general request form at IANA but then they will probably say that you need an RFC and bladiebla... while I just want to let people test it first ;) You need implementations of a thing anyway before it can become an rfc usually, this there is a small loop there. Greets, Jeroen PS: Yes, draft-ietf-multi6-things-to-think-about questions are answered positively and no dependency on DNS etc ;) --=-rCS4uddCO/ctLqScqRnR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBRUCVKaooUjM+fCMRAkpwAJ98HPEQSzZHevrYrjzaVrrYwTaQ+ACfUl+8 9bdck/G78gM0NnTm3E8YY7E= =ZjVZ -----END PGP SIGNATURE----- --=-rCS4uddCO/ctLqScqRnR-- From owner-v6ops@ops.ietf.org Mon Sep 13 03:15:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01832 for ; Mon, 13 Sep 2004 03:15:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C6l2h-000NPT-93 for v6ops-data@psg.com; Mon, 13 Sep 2004 07:14:27 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C6l2V-000NOP-NC for v6ops@ops.ietf.org; Mon, 13 Sep 2004 07:14:16 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 66708800D for ; Mon, 13 Sep 2004 09:14:13 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 10615-79 for ; Mon, 13 Sep 2004 09:14:06 +0200 (CEST) Received: from [9.4.69.44] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id EF2907F68 for ; Mon, 13 Sep 2004 09:14:04 +0200 (CEST) Subject: Re: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft From: Jeroen Massar To: V6OPS WG Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5kNq250b6d7WcWlpI2ZH" Organization: Unfix Message-Id: <1095059637.2608.310.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 13 Sep 2004 09:13:57 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-5kNq250b6d7WcWlpI2ZH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Karen E. Nielsen wrote: > So what you're saying is that the Tunnel Server can rely on the > information from the IPv4 layer and thus does not need glue > native IPv6 NUD-like mechanism on top of the IPv4 layer - ? Correct. > > The real way to fix this is doing egress/ingress filtering on IPv4... > > But many ISP's do not do any filtering at all, so tough luck. > > For that matter, the not so many IPv6 ISP's that are out there don't > > filter on IPv6 either, at least most of them, so most are=20 > > repeating the > > same problem again, but all has to do with the router not=20 > > being able to > > do filtering or something on linerate... >=20 > Neither of these are real problems in the particular scenario of > zeroconf, due to its severe assumptions on IPv4 source filtering and=20 > source spoof preventions. Which should indeed be there, but are not in most cases. Then again, using spoofing to do DDoS's is not needed when the kiddy people have 50k host big botnets at their disposal. > A different issue however is that the server may be swamped with > ICMP proto-41 unreachable from IPv4 nodes in the case where the > server is used to reflect packets into the network. I have seen quite a number of icmp unreachable's coming onto one of the Tunnel Servers we have, when people turned off their proto-41 or when the route was unavailable etc. Fortunatly these are only icmp's and thus doesn't cost most in terms of bandwidth etc. One of the solutions is proto41-Heartbeat, let the client send a heartbeat every now and then to the Tunnel Server, if it doesn't do that just shutdown the tunnel. Then again, I do not know of anyone having a Tunnel Server which has more than 5000 tunnels connected to it. Maybe the Hexago people have more experience in that direction of volume of users ? Greets, Jeroen --=-5kNq250b6d7WcWlpI2ZH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBRUizKaooUjM+fCMRAqJ6AJ9ZAEwDvKFxMnfrfzUhmcZ4en07+ACgmNwg RutzwP66Cup9S0x9CYN8P4k= =ad6H -----END PGP SIGNATURE----- --=-5kNq250b6d7WcWlpI2ZH-- From owner-v6ops@ops.ietf.org Mon Sep 13 08:44:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24217 for ; Mon, 13 Sep 2004 08:44:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C6qA7-0007KF-QK for v6ops-data@psg.com; Mon, 13 Sep 2004 12:42:27 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C6q8u-0007B1-Ac for v6ops@ops.ietf.org; Mon, 13 Sep 2004 12:41:12 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8DCemfQ133960; Mon, 13 Sep 2004 12:40:48 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8DCelmk202992; Mon, 13 Sep 2004 14:40:47 +0200 Received: from zurich.ibm.com (sig-9-145-244-148.de.ibm.com [9.145.244.148]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA79340; Mon, 13 Sep 2004 14:40:45 +0200 Message-ID: <4145954D.9040705@zurich.ibm.com> Date: Mon, 13 Sep 2004 14:40:45 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Karen E. Nielsen (AH/TED)" CC: "'Pekka Savola'" , V6OPS WG , "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" Subject: Re: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen E. Nielsen (AH/TED) wrote: > Dear All, > > An issue of general character has been brought up in connection with the zero-conf work. > The issue is the following: > > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support NUD-like mechanisms that enables > them to send ICMP destination unreachable messages back to origin ? > > The initial feedback received in this respect is that - "yes, they MUST". > > As some RFCs previously has been silent about this, e.g. 6to4 - RFC 3056, > and the working group currently is standardising a mechanism which also seems > to be silent about this (Teredo) I would very much like to hear if the above is the > general sentiment of the work group. To be clear, are you asking about ICMPv4 or ICMPv6 responses? Brian > > I should be stressed that adding this to the goals of the zero-conf requirements > document isn't believed to severely limit the solution space - but it requires > implementation of a mechanism which is know to scale very badly and > which in addition is susceptible to the DoS attack described in Section 4.3.2 of RFC 3756. > > BR, Karen > > >> >>On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: >> >>>Normally last hops routers performs NUD so that they can send ICMPs >>>back to origin to notify of black holes/unreachability. Personally >>>I am not sure that this is a MUST requirement on the Tunnel Servers. >>>I have actually thought that we could avoid this, especially since >>>we have no explicit goals as to the nodes being registered as >>>reachable in the DNS using the Ipv6 address - wherefore we are first >>>and foremost looking to support the situation where communication is >>>initiated by the tunnel clients and not from the outside. >> >>This seems short-sighted to me, because the actual *advantage* of IPv6 >>is realized only when *incoming* connectivity is enabled (if it was >>just about outbound connectivity, v4 would work as well). > > If this > >>would imply that the communication between two nodes inside the 3GPP >>network or communication originating from IPv6 internet and coming to >>a 3GPP node could just silently fail.. this would seem to be very >>undesirable. > > > Note this is not about the connectivity silently failing, it > is about the node no longer being there/no longer being active. > > But what you're saying is that the destination unreachable ICMPs are a MUST > to support at a Ipv6-in-Ipv4 Tunnel Server ? > > - BTW, with the risk of bluring the difference in between > solution space and requirement space - I suppose this in particular applies > to the v6ops accepted "tunnel server" mechanisms, 6to4 and Teredo border routers ? > > >>-- >>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 Mon Sep 13 09:24:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28324 for ; Mon, 13 Sep 2004 09:24:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C6qo2-000Csq-Ej for v6ops-data@psg.com; Mon, 13 Sep 2004 13:23:42 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C6qna-000Cnh-L4 for v6ops@ops.ietf.org; Mon, 13 Sep 2004 13:23:15 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8DDNClU020051 for ; Mon, 13 Sep 2004 15:23:12 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 15:23:12 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SMG4B6J8; Mon, 13 Sep 2004 15:23:12 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Sep 2004 15:23:12 +0200 Message-ID: X-Sybari-Trust: 1a59201c 74898554 b86a33b5 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Brian E Carpenter'" Cc: "'Pekka Savola'" , V6OPS WG , "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com, "'Jeroen Massar'" Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Mon, 13 Sep 2004 15:23:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Sep 2004 13:23:12.0231 (UTC) FILETIME=[D180DF70:01C49994] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Brian, I probably wasn't very clear because I wasn't thinking about translation of ICMP proto-41 unreachable messages. Let me try to clarify my question. A tunnel server, which IPv6-in-IPv4 encapsulates packets to dual stack end-hosts, acts as a last hop IPv6 router at the IPv6 level. Examples of such a server is a Teredo server, and Isatap server as well as a 6to4 tunnel server (when the server-to-host 6to4 case is supported) Now a standard last hop IPv6 router on a lan monitors the reachability of its lan hosts using NUD and notifies of black holes by sending IPv6 destination unreachable back to origin. (Actually the ICMP is generated when a NUD cache times out and address resolution cannot be performed anew, but in this context that's a detail.) My question is: What are the requirements on tunnel servers in this respect - that is, is it required that a tunnel server performs IPv6 reachability monitoring comparatively to the above, meaning something which results in it being able to send IPv6 ICMPs back to origin when a packet doesn't reach an end-host (at the IPv6 level) ?? Ultimatively that would mean that some IPv6 NUD like mechanism would have to be glued on top of the tunnelservice. Given the answer from Jereon about translation of IPv4 ICMP proto-41 - it could be that the answer to the question is - "NO that is not required. It suffices that the tunnel server aims to translate all proto-41 unreach IPv4 ICMP's into IPv6 destination unreachables which are sent back to origin." This also means that whether black holes are detected or not, relies on the benevolence of the end-hosts to generate proto-41 unreach ICMPs (and large enough such messages, i.e. messages which includes original Ipv6 header) and not on (stateful) mechanisms implemented by the tunnel server. My new question is then - is the proto-41 translation scheme the general mech adopted for (and accepted for) this purpose by the WG ? BR, Karen > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Monday, September 13, 2004 2:41 PM > To: Karen E. Nielsen (AH/TED) > Cc: 'Pekka Savola'; V6OPS WG; 'Radhakrishnan Suryanarayanan'; > juha.wiljakka@nokia.com; 'Soininen Jonne (Nokia-NET/Helsinki)' > Subject: Re: Unreachability detection at tunnels servers WAS: RE: > Comments on zeroconf draft > > > Karen E. Nielsen (AH/TED) wrote: > > Dear All, > > > > An issue of general character has been brought up in > connection with the zero-conf work. > > The issue is the following: > > > > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support > NUD-like mechanisms that enables > > them to send ICMP destination unreachable messages back to origin ? > > > > The initial feedback received in this respect is that - > "yes, they MUST". > > > > As some RFCs previously has been silent about this, e.g. > 6to4 - RFC 3056, > > and the working group currently is standardising a > mechanism which also seems > > to be silent about this (Teredo) I would very much like to > hear if the above is the > > general sentiment of the work group. > > To be clear, are you asking about ICMPv4 or ICMPv6 responses? > > Brian > > > > > I should be stressed that adding this to the goals of the > zero-conf requirements > > document isn't believed to severely limit the solution > space - but it requires > > implementation of a mechanism which is know to scale very badly and > > which in addition is susceptible to the DoS attack > described in Section 4.3.2 of RFC 3756. > > > > BR, Karen > > > > > >> > >>On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > >> > >>>Normally last hops routers performs NUD so that they can send ICMPs > >>>back to origin to notify of black holes/unreachability. Personally > >>>I am not sure that this is a MUST requirement on the > Tunnel Servers. > >>>I have actually thought that we could avoid this, especially since > >>>we have no explicit goals as to the nodes being registered as > >>>reachable in the DNS using the Ipv6 address - wherefore we > are first > >>>and foremost looking to support the situation where > communication is > >>>initiated by the tunnel clients and not from the outside. > >> > >>This seems short-sighted to me, because the actual > *advantage* of IPv6 > >>is realized only when *incoming* connectivity is enabled (if it was > >>just about outbound connectivity, v4 would work as well). > > > > If this > > > >>would imply that the communication between two nodes inside the 3GPP > >>network or communication originating from IPv6 internet and > coming to > >>a 3GPP node could just silently fail.. this would seem to be very > >>undesirable. > > > > > > Note this is not about the connectivity silently failing, it > > is about the node no longer being there/no longer being active. > > > > But what you're saying is that the destination unreachable > ICMPs are a MUST > > to support at a Ipv6-in-Ipv4 Tunnel Server ? > > > > - BTW, with the risk of bluring the difference in between > > solution space and requirement space - I suppose this in > particular applies > > to the v6ops accepted "tunnel server" mechanisms, 6to4 and > Teredo border routers ? > > > > > >>-- > >>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 Mon Sep 13 11:10:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07512 for ; Mon, 13 Sep 2004 11:10:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C6sPQ-0003I3-V5 for v6ops-data@psg.com; Mon, 13 Sep 2004 15:06:24 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C6sPG-0003Fh-BS for v6ops@ops.ietf.org; Mon, 13 Sep 2004 15:06:14 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 96D4F800D; Mon, 13 Sep 2004 17:06:10 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 15072-99; Mon, 13 Sep 2004 17:06:06 +0200 (CEST) Received: from [9.4.69.44] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 79B587F68; Mon, 13 Sep 2004 17:06:06 +0200 (CEST) Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft From: Jeroen Massar To: "Karen E. Nielsen (AH/TED)" Cc: V6OPS WG In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PDCJTJZSQEzDsjaqqtEb" Organization: Unfix Message-Id: <1095087964.2608.531.camel@segesta.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 13 Sep 2004 17:06:04 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-PDCJTJZSQEzDsjaqqtEb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-09-13 at 15:23, Karen E. Nielsen (AH/TED) wrote: > Hi Brian, > My new question is then - is the proto-41 translation scheme the general= mech > adopted for (and accepted for) this purpose by the WG ? You mean that errors in IPv4 space should be converted to errors in IPv6 space? Greets,=20 Jeroen --=-PDCJTJZSQEzDsjaqqtEb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBRbdcKaooUjM+fCMRAs/nAJ4vlIYpfPNbryQH7K0D02EPq/sfagCgsPok suHebcFgJ9qKltu4q1KGdjM= =xHCM -----END PGP SIGNATURE----- --=-PDCJTJZSQEzDsjaqqtEb-- From owner-v6ops@ops.ietf.org Tue Sep 14 00:02:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12202 for ; Tue, 14 Sep 2004 00:02:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C74TV-000EAG-1U for v6ops-data@psg.com; Tue, 14 Sep 2004 03:59:25 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C74TK-000E89-An for v6ops@ops.ietf.org; Tue, 14 Sep 2004 03:59:14 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 13 Sep 2004 20:59:08 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 20:59:14 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Sep 2004 20:59:14 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 13 Sep 2004 20:59:13 -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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Mon, 13 Sep 2004 20:59:13 -0700 Message-ID: Thread-Topic: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft thread-index: AcSZlZ7oHm+ZSYCpSlSU+e4VC5JeGAAeI5bw From: "Christian Huitema" To: "Karen E. Nielsen \(AH/TED\)" , "Brian E Carpenter" Cc: "Pekka Savola" , "V6OPS WG" , "Radhakrishnan Suryanarayanan" , , "Jeroen Massar" X-OriginalArrivalTime: 14 Sep 2004 03:59:13.0199 (UTC) FILETIME=[32481BF0:01C49A0F] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Now a standard last hop IPv6 router on a lan monitors the reachability of > its lan hosts using NUD and notifies of black holes by sending IPv6 > destination unreachable > back to origin. (Actually the ICMP is generated when a NUD cache times out > and address resolution cannot be performed anew, but in this context=20 > that's a detail.) I don't think that in this age of firewalls, any application should rely on ICMP packets for detecting that a destination is not reachable. Most firewalls are programmed to silently drop the traffic they don't like... That being said, Teredo hosts and relays can in fact use the Teredo bubble mechanism to verify that their peers are reachable. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Sep 14 02:28:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06464 for ; Tue, 14 Sep 2004 02:28:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C76lh-00046Z-7A for v6ops-data@psg.com; Tue, 14 Sep 2004 06:26:21 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C76lO-000452-3P for v6ops@ops.ietf.org; Tue, 14 Sep 2004 06:26:02 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I4000IHCPVCPQ@mailout2.samsung.com> for v6ops@ops.ietf.org; Tue, 14 Sep 2004 15:26:00 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I4000HRPPTYR8@mailout2.samsung.com> for v6ops@ops.ietf.org; Tue, 14 Sep 2004 15:25:10 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I4000N7LPTU2B@mmp2.samsung.com> for v6ops@ops.ietf.org; Tue, 14 Sep 2004 15:25:10 +0900 (KST) Date: Tue, 14 Sep 2004 11:54:32 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: Unreachability detection at tunnels servers WAS: RE: Comments onzeroconf draft To: "Karen E. Nielsen (AH/TED)" , "'Brian E Carpenter'" Cc: "'Pekka Savola'" , V6OPS WG , juha.wiljakka@nokia.com, "'Jeroen Massar'" Reply-to: Radhakrishnan Suryanarayanan Message-id: <08db01c49a23$80c9d3e0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Karen, > My new question is then - is the proto-41 translation scheme the general mech > adopted for (and accepted for) this purpose by the WG ? IMHO, the transition mechanisms should provide handling ICMPv4 errors and their translation. "Basic Transition Mechanisms for IPv6 Hosts and Routers" section 3.4 is doing it. Isnt this a good indicator? From owner-v6ops@ops.ietf.org Tue Sep 14 03:15:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10000 for ; Tue, 14 Sep 2004 03:15:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C77U3-0009V7-8T for v6ops-data@psg.com; Tue, 14 Sep 2004 07:12:11 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C77Tq-0009Ti-1O for v6ops@ops.ietf.org; Tue, 14 Sep 2004 07:11:58 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8E7BrWR012088 for ; Tue, 14 Sep 2004 09:11:57 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 09:11:53 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SNX3JKQM; Tue, 14 Sep 2004 09:11:53 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Sep 2004 09:11:53 +0200 Message-ID: X-Sybari-Trust: fbb26392 47b3073a e26192c2 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Jeroen Massar'" Cc: V6OPS WG Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Tue, 14 Sep 2004 09:11:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Sep 2004 07:11:53.0747 (UTC) FILETIME=[1CE7BE30:01C49A2A] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > > > My new question is then - is the proto-41 translation > scheme the general mech > > adopted for (and accepted for) this purpose by the WG ? > > You mean that errors in IPv4 space should be converted to > errors in IPv6 > space? > I mean whether it is considered sufficient/good enough for for Tunnel Server reachability detection to rely on translation of IPv4 ICMPs only. BR, Karen From owner-v6ops@ops.ietf.org Tue Sep 14 03:23:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10912 for ; Tue, 14 Sep 2004 03:23:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C77ep-000AYK-Rl for v6ops-data@psg.com; Tue, 14 Sep 2004 07:23:19 +0000 Received: from [193.180.251.53] (helo=eagle.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C77ee-000AXY-S9 for v6ops@ops.ietf.org; Tue, 14 Sep 2004 07:23:09 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8E7N8Ah017300 for ; Tue, 14 Sep 2004 09:23:08 +0200 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 09:23:07 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SMG4LQ6C; Tue, 14 Sep 2004 09:23:07 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Sep 2004 09:23:07 +0200 Message-ID: X-Sybari-Trust: 54b98356 74898554 d15b10ac 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Christian Huitema'" , Brian E Carpenter Cc: Pekka Savola , V6OPS WG , Radhakrishnan Suryanarayanan , juha.wiljakka@nokia.com, Jeroen Massar Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Tue, 14 Sep 2004 09:23:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Sep 2004 07:23:07.0907 (UTC) FILETIME=[AEBC6530:01C49A2B] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Christian, > > > Now a standard last hop IPv6 router on a lan monitors the > reachability > of > > its lan hosts using NUD and notifies of black holes by sending IPv6 > > destination unreachable > > back to origin. (Actually the ICMP is generated when a NUD > cache times > out > > and address resolution cannot be performed anew, but in > this context > > that's a detail.) > > I don't think that in this age of firewalls, any application > should rely > on ICMP packets for detecting that a destination is not > reachable. Most > firewalls are programmed to silently drop the traffic they > don't like... > I don't disagree. The problem is with the alternative. > That being said, Teredo hosts and relays can in fact use the Teredo > bubble mechanism to verify that their peers are reachable. > Does this mean that Teredo Servers perform (or are meant to perform, i.e. SHOULD - ?) some kind of RFC 2461 NUD-like reachability mechanism using the bubble mechanism, when the reachability of end-host are in question ? - Or is it rather so that vendors if they like could implement this ? BR, Karen From owner-v6ops@ops.ietf.org Tue Sep 14 03:26:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11111 for ; Tue, 14 Sep 2004 03:26:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C77h9-000And-3K for v6ops-data@psg.com; Tue, 14 Sep 2004 07:25:43 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C77ga-000AjH-5N for v6ops@ops.ietf.org; Tue, 14 Sep 2004 07:25:08 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8E7E4WR012858 for ; Tue, 14 Sep 2004 09:14:04 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 09:14:04 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SY7NY245; Tue, 14 Sep 2004 09:14:04 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Sep 2004 09:14:04 +0200 Message-ID: X-Sybari-Trust: d69697c6 74898554 d15b10ac 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" , "'Brian E Carpenter'" Cc: "'Pekka Savola'" , V6OPS WG , juha.wiljakka@nokia.com, "'Jeroen Massar'" Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments onzeroconf draft Date: Tue, 14 Sep 2004 09:13:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Sep 2004 07:14:04.0748 (UTC) FILETIME=[6AFCE8C0:01C49A2A] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Radhakrishnan, > > Hi Karen, > > > My new question is then - is the proto-41 translation > scheme the general > mech > > adopted for (and accepted for) this purpose by the WG ? > IMHO, the transition mechanisms should provide handling > ICMPv4 errors and > their translation. > "Basic Transition Mechanisms for IPv6 Hosts and Routers" > section 3.4 is doing it. > Isnt this a good > indicator? > Yes, mech-v2 is saying that IPv4 ICMPs should be translated, but it also says, Section 3.8, that IPv6 NUD SHOULD be performed. BR, Karen From owner-v6ops@ops.ietf.org Tue Sep 14 04:56:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17355 for ; Tue, 14 Sep 2004 04:56:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C795R-000KE1-6P for v6ops-data@psg.com; Tue, 14 Sep 2004 08:54:53 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C795G-000KCk-E4 for v6ops@ops.ietf.org; Tue, 14 Sep 2004 08:54:42 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I4000KMLWR4QG@mailout2.samsung.com> for v6ops@ops.ietf.org; Tue, 14 Sep 2004 17:54:41 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I4000HSWWPPR8@mailout2.samsung.com> for v6ops@ops.ietf.org; Tue, 14 Sep 2004 17:53:49 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I40009N2WPMGV@mmp2.samsung.com> for v6ops@ops.ietf.org; Tue, 14 Sep 2004 17:53:49 +0900 (KST) Date: Tue, 14 Sep 2004 14:23:11 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: Unreachability detection at tunnels servers WAS: RE: Comments onzeroconf draft To: "Karen E. Nielsen (AH/TED)" , "'Brian E Carpenter'" Cc: "'Pekka Savola'" , V6OPS WG , juha.wiljakka@nokia.com, "'Jeroen Massar'" Reply-to: Radhakrishnan Suryanarayanan Message-id: <092a01c49a38$451ea9a0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > Yes, mech-v2 is saying that IPv4 ICMPs should be translated, but it also > says, Section 3.8, that IPv6 NUD SHOULD be performed. mech-v2 says IPv4 ICMP error messages other than "packet too big" MAY be translated. But "packet too big" translation should be done as it is used for determining IPv6 PMTU when IPv4 acts as a link-layer for IPv6. ICMPv4 Destination unreachable (particularly Host & network unreachable) errors do help the last-hop IPv6 router (tunnel server ) in determining the reachability of end-node's IPv4 address which is the tunnel's end-point. So translation helps in such cases to speed up the unreachability detection. If IPv6 NUD is also supported then we can either translate the ICMPv4 error messages (faster) or cache out the NUD entry if address resolution fails. The tunnel server must support "packet too big" translation anyway for IPv6 PMTU. so as well have a couple of other error messages translated as well which can be helpful. IMHO, ICMPv4 error message translation & IPv6 NUD both should be supported. Regards Radhakrishnan From owner-v6ops@ops.ietf.org Wed Sep 15 04:12:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10936 for ; Wed, 15 Sep 2004 04:12:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C7UpK-0001Yb-0a for v6ops-data@psg.com; Wed, 15 Sep 2004 08:07:42 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C7Up8-0001WE-H6 for v6ops@ops.ietf.org; Wed, 15 Sep 2004 08:07:31 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8F87TWR020999 for ; Wed, 15 Sep 2004 10:07:29 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 10:07:29 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SNX3YM3P; Wed, 15 Sep 2004 10:07:29 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Sep 2004 10:07:28 +0200 Message-ID: X-Sybari-Trust: 710e4774 47b3073a 0a4d5d34 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" , "'Brian E Carpenter'" Cc: "'Pekka Savola'" , V6OPS WG , juha.wiljakka@nokia.com, "'Jeroen Massar'" Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments onzeroconf draft Date: Wed, 15 Sep 2004 10:07:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 15 Sep 2004 08:07:29.0008 (UTC) FILETIME=[0B49EF00:01C49AFB] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Radhakrisnan, [snip] > > If IPv6 NUD is also supported then we can either translate > the ICMPv4 error > messages (faster) or cache out the NUD entry if address > resolution fails. Note that I am talking about RFC 2461 "NUD-like" mechanism, as RFC 2461 NUD is based on the fact that address resolution gives proof of reachability. This may not be the case on the tunnel links, e.g. in Teredo, 6to4 and Isatap, where address resolution in itself may not provide proof of reachability. > The tunnel server must support "packet too big" translation > anyway for IPv6 > PMTU. so as well have a couple of other error messages > translated as well > which can be helpful. > > IMHO, ICMPv4 error message translation & IPv6 NUD both should > be supported. > OK, that's clear talk. Thanks. I am still looking for the general sentiment in the WG on this, though. Any opinions ? BR, Karen > Regards > Radhakrishnan > From owner-v6ops@ops.ietf.org Wed Sep 15 05:48:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17471 for ; Wed, 15 Sep 2004 05:48:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C7WMI-000CDg-7y for v6ops-data@psg.com; Wed, 15 Sep 2004 09:45:50 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C7WM6-000CCg-Q3 for v6ops@ops.ietf.org; Wed, 15 Sep 2004 09:45:39 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8F9jJnO104128; Wed, 15 Sep 2004 09:45:19 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8F9jIJL104008; Wed, 15 Sep 2004 11:45:18 +0200 Received: from zurich.ibm.com (sig-9-145-134-57.de.ibm.com [9.145.134.57]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA77522; Wed, 15 Sep 2004 11:45:17 +0200 Message-ID: <41480F2C.2070608@zurich.ibm.com> Date: Wed, 15 Sep 2004 11:45:16 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Karen E. Nielsen (AH/TED)" CC: "'Pekka Savola'" , V6OPS WG , "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com, "'Jeroen Massar'" Subject: Re: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen, Thanks for the clarification. One comment below.. Karen E. Nielsen (AH/TED) wrote: > Hi Brian, > > I probably wasn't very clear because I wasn't thinking about > translation of ICMP proto-41 unreachable messages. Let me try to clarify > my question. > > A tunnel server, which IPv6-in-IPv4 encapsulates > packets to dual stack end-hosts, acts as a last hop IPv6 router at the > IPv6 level. > > Examples of such a server is a Teredo server, and Isatap server as well > as a 6to4 tunnel server (when the server-to-host 6to4 case is supported) And that is not described in RFC 3056, so isn't part of standardized 6to4. A 6to4 router, as described in RFC 3056, is like any other IPv6 router as far as NUD and ICMPv6 is concerned - there is nothing special for the 6to4 decapsulator to do in this respect. The router function does what any router does. A host which claims to support RFC 3056 really needs to behave like a 6to4 router. To be clear, it acts as its own last hop router. It's forwarding the decapsulated IPv6 packets to a local IPv6 stack. If that forwarding action fails it should generate an ICMPv6 unreachable response. (It's a very bizarre error condition though, and probably can never happen in reality. Why would there be a 6to4 decapsulator operating, if there is no local IPv6 stack?) A 6to4 encapsulator can only detect IPv4 unreachability, which in IPv6 terms is a link failure and should obviously be handled like any other link failure. 6to4 was designed to be orthogonal to everything else; generic tunnel servers are different and your questions below certainly apply to them. Brian > > Now a standard last hop IPv6 router on a lan monitors the reachability of its > lan hosts using NUD and notifies of black holes by sending IPv6 destination unreachable > back to origin. (Actually the ICMP is generated when a NUD cache times out and > address resolution cannot be performed anew, but in this context that's a detail.) > > My question is: > > What are the requirements on tunnel servers in this respect - that is, is it required > that a tunnel server performs IPv6 reachability monitoring comparatively to the above, > meaning something which results in it being able to send IPv6 ICMPs back to origin > when a packet doesn't reach an end-host (at the IPv6 level) ?? > > Ultimatively that would mean that some IPv6 NUD like mechanism would have to be glued > on top of the tunnelservice. > > Given the answer from Jereon about translation of IPv4 ICMP proto-41 - > it could be that the answer to the question is - "NO that is not required. It suffices > that the tunnel server aims to translate all proto-41 unreach IPv4 ICMP's into > IPv6 destination unreachables which are sent back to origin." > > This also means that whether black holes are detected or not, relies on the benevolence > of the end-hosts to generate proto-41 unreach ICMPs (and large enough such messages, i.e. messages which includes original Ipv6 header) and not on (stateful) mechanisms implemented > by the tunnel server. > > My new question is then - is the proto-41 translation scheme the general mech > adopted for (and accepted for) this purpose by the WG ? > > > BR, Karen > > >>-----Original Message----- >>From: Brian E Carpenter [mailto:brc@zurich.ibm.com] >>Sent: Monday, September 13, 2004 2:41 PM >>To: Karen E. Nielsen (AH/TED) >>Cc: 'Pekka Savola'; V6OPS WG; 'Radhakrishnan Suryanarayanan'; >>juha.wiljakka@nokia.com; 'Soininen Jonne (Nokia-NET/Helsinki)' >>Subject: Re: Unreachability detection at tunnels servers WAS: RE: >>Comments on zeroconf draft >> >> >>Karen E. Nielsen (AH/TED) wrote: >> >>>Dear All, >>> >>>An issue of general character has been brought up in >> >>connection with the zero-conf work. >> >>>The issue is the following: >>> >>>MUST Ipv6-in-Ipv4 tunnel servers, as routers, support >> >>NUD-like mechanisms that enables >> >>>them to send ICMP destination unreachable messages back to origin ? >>> >>>The initial feedback received in this respect is that - >> >>"yes, they MUST". >> >>>As some RFCs previously has been silent about this, e.g. >> >>6to4 - RFC 3056, >> >>>and the working group currently is standardising a >> >>mechanism which also seems >> >>>to be silent about this (Teredo) I would very much like to >> >>hear if the above is the >> >>>general sentiment of the work group. >> >>To be clear, are you asking about ICMPv4 or ICMPv6 responses? >> >> Brian >> >> >>>I should be stressed that adding this to the goals of the >> >>zero-conf requirements >> >>>document isn't believed to severely limit the solution >> >>space - but it requires >> >>>implementation of a mechanism which is know to scale very badly and >>>which in addition is susceptible to the DoS attack >> >>described in Section 4.3.2 of RFC 3756. >> >>>BR, Karen >>> >>> >>> >>>>On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: >>>> >>>> >>>>>Normally last hops routers performs NUD so that they can send ICMPs >>>>>back to origin to notify of black holes/unreachability. Personally >>>>>I am not sure that this is a MUST requirement on the >> >>Tunnel Servers. >> >>>>>I have actually thought that we could avoid this, especially since >>>>>we have no explicit goals as to the nodes being registered as >>>>>reachable in the DNS using the Ipv6 address - wherefore we >> >>are first >> >>>>>and foremost looking to support the situation where >> >>communication is >> >>>>>initiated by the tunnel clients and not from the outside. >>>> >>>>This seems short-sighted to me, because the actual >> >>*advantage* of IPv6 >> >>>>is realized only when *incoming* connectivity is enabled (if it was >>>>just about outbound connectivity, v4 would work as well). >>> >>> If this >>> >>> >>>>would imply that the communication between two nodes inside the 3GPP >>>>network or communication originating from IPv6 internet and >> >>coming to >> >>>>a 3GPP node could just silently fail.. this would seem to be very >>>>undesirable. >>> >>> >>>Note this is not about the connectivity silently failing, it >>>is about the node no longer being there/no longer being active. >>> >>>But what you're saying is that the destination unreachable >> >>ICMPs are a MUST >> >>>to support at a Ipv6-in-Ipv4 Tunnel Server ? >>> >>>- BTW, with the risk of bluring the difference in between >>>solution space and requirement space - I suppose this in >> >>particular applies >> >>>to the v6ops accepted "tunnel server" mechanisms, 6to4 and >> >>Teredo border routers ? >> >>> >>>>-- >>>>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 Wed Sep 15 08:43:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28941 for ; Wed, 15 Sep 2004 08:43:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C7Z5F-0007Fw-1Q for v6ops-data@psg.com; Wed, 15 Sep 2004 12:40:25 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C7Z4t-0007C3-OU for v6ops@ops.ietf.org; Wed, 15 Sep 2004 12:40:04 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8FCe2lU009178 for ; Wed, 15 Sep 2004 14:40:02 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 14:40:02 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id SMG460A1; Wed, 15 Sep 2004 14:34:21 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Sep 2004 14:34:22 +0200 Message-ID: X-Sybari-Trust: b2d28fc6 74898554 a4a0e7e3 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Brian E Carpenter'" Cc: "'Pekka Savola'" , V6OPS WG , "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com, "'Jeroen Massar'" Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Wed, 15 Sep 2004 14:34:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 15 Sep 2004 12:40:02.0547 (UTC) FILETIME=[1EC1F430:01C49B21] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Brian, Thanks a lot for your comments. Left is how to get an answer to the general question, though. A few comments below. > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Wednesday, September 15, 2004 11:45 AM > To: Karen E. Nielsen (AH/TED) > Cc: 'Pekka Savola'; V6OPS WG; 'Radhakrishnan Suryanarayanan'; > juha.wiljakka@nokia.com; 'Jeroen Massar' > Subject: Re: Unreachability detection at tunnels servers WAS: RE: > Comments on zeroconf draft > > > Karen, > > Thanks for the clarification. One comment below.. > > Karen E. Nielsen (AH/TED) wrote: > > Hi Brian, > > > > I probably wasn't very clear because I wasn't thinking about > > translation of ICMP proto-41 unreachable messages. Let me > try to clarify > > my question. > > > > A tunnel server, which IPv6-in-IPv4 encapsulates > > packets to dual stack end-hosts, acts as a last hop IPv6 > router at the > > IPv6 level. > > > > Examples of such a server is a Teredo server, and Isatap > server as well > > as a 6to4 tunnel server (when the server-to-host 6to4 case > is supported) > > And that is not described in RFC 3056, so isn't part of standardized > 6to4. A 6to4 router, as described in RFC 3056, is like any other IPv6 > router as far as NUD and ICMPv6 is concerned - there is nothing > special for the 6to4 decapsulator to do in this respect. The router > function does what any router does. > Agreed. > A host which claims to support RFC 3056 really needs to behave like > a 6to4 router. To be clear, it acts as its own last hop router. > It's forwarding the decapsulated IPv6 packets to a local IPv6 stack. > If that forwarding action fails it should generate an ICMPv6 > unreachable > response. (It's a very bizarre error condition though, and > probably can > never happen in reality. Why would there be a 6to4 > decapsulator operating, > if there is no local IPv6 stack?) > > A 6to4 encapsulator can only detect IPv4 unreachability, which in IPv6 > terms is a link failure and should obviously be handled like any other > link failure. > Well, an 6to4 encapsulator could perform NUD on the IPv6 level even on the router-to-router links. RFC 3056 even has a reference to RFC 2893 in this respect, only the reference, in my mind, isn't clear (and furthermore it is quickly becoming deprecate). But going into that discussion is of-topic and different from the issue that I wanted to raise with this thread. > 6to4 was designed to be orthogonal to everything else; generic tunnel > servers are different and your questions below certainly > apply to them. > Good. Thanks, Karen > Brian > > > > > Now a standard last hop IPv6 router on a lan monitors the > reachability of its > > lan hosts using NUD and notifies of black holes by sending > IPv6 destination unreachable > > back to origin. (Actually the ICMP is generated when a NUD > cache times out and > > address resolution cannot be performed anew, but in this > context that's a detail.) > > > > My question is: > > > > What are the requirements on tunnel servers in this respect > - that is, is it required > > that a tunnel server performs IPv6 reachability monitoring > comparatively to the above, > > meaning something which results in it being able to send > IPv6 ICMPs back to origin > > when a packet doesn't reach an end-host (at the IPv6 level) ?? > > > > Ultimatively that would mean that some IPv6 NUD like > mechanism would have to be glued > > on top of the tunnelservice. > > > > Given the answer from Jereon about translation of IPv4 ICMP > proto-41 - > > it could be that the answer to the question is - "NO that > is not required. It suffices > > that the tunnel server aims to translate all proto-41 > unreach IPv4 ICMP's into > > IPv6 destination unreachables which are sent back to origin." > > > > This also means that whether black holes are detected or > not, relies on the benevolence > > of the end-hosts to generate proto-41 unreach ICMPs (and > large enough such messages, i.e. messages which includes > original Ipv6 header) and not on (stateful) mechanisms implemented > > by the tunnel server. > > > > My new question is then - is the proto-41 translation > scheme the general mech > > adopted for (and accepted for) this purpose by the WG ? > > > > > > BR, Karen > > > > > >>-----Original Message----- > >>From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > >>Sent: Monday, September 13, 2004 2:41 PM > >>To: Karen E. Nielsen (AH/TED) > >>Cc: 'Pekka Savola'; V6OPS WG; 'Radhakrishnan Suryanarayanan'; > >>juha.wiljakka@nokia.com; 'Soininen Jonne (Nokia-NET/Helsinki)' > >>Subject: Re: Unreachability detection at tunnels servers WAS: RE: > >>Comments on zeroconf draft > >> > >> > >>Karen E. Nielsen (AH/TED) wrote: > >> > >>>Dear All, > >>> > >>>An issue of general character has been brought up in > >> > >>connection with the zero-conf work. > >> > >>>The issue is the following: > >>> > >>>MUST Ipv6-in-Ipv4 tunnel servers, as routers, support > >> > >>NUD-like mechanisms that enables > >> > >>>them to send ICMP destination unreachable messages back to origin ? > >>> > >>>The initial feedback received in this respect is that - > >> > >>"yes, they MUST". > >> > >>>As some RFCs previously has been silent about this, e.g. > >> > >>6to4 - RFC 3056, > >> > >>>and the working group currently is standardising a > >> > >>mechanism which also seems > >> > >>>to be silent about this (Teredo) I would very much like to > >> > >>hear if the above is the > >> > >>>general sentiment of the work group. > >> > >>To be clear, are you asking about ICMPv4 or ICMPv6 responses? > >> > >> Brian > >> > >> > >>>I should be stressed that adding this to the goals of the > >> > >>zero-conf requirements > >> > >>>document isn't believed to severely limit the solution > >> > >>space - but it requires > >> > >>>implementation of a mechanism which is know to scale very badly and > >>>which in addition is susceptible to the DoS attack > >> > >>described in Section 4.3.2 of RFC 3756. > >> > >>>BR, Karen > >>> > >>> > >>> > >>>>On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > >>>> > >>>> > >>>>>Normally last hops routers performs NUD so that they can > send ICMPs > >>>>>back to origin to notify of black holes/unreachability. > Personally > >>>>>I am not sure that this is a MUST requirement on the > >> > >>Tunnel Servers. > >> > >>>>>I have actually thought that we could avoid this, > especially since > >>>>>we have no explicit goals as to the nodes being registered as > >>>>>reachable in the DNS using the Ipv6 address - wherefore we > >> > >>are first > >> > >>>>>and foremost looking to support the situation where > >> > >>communication is > >> > >>>>>initiated by the tunnel clients and not from the outside. > >>>> > >>>>This seems short-sighted to me, because the actual > >> > >>*advantage* of IPv6 > >> > >>>>is realized only when *incoming* connectivity is enabled > (if it was > >>>>just about outbound connectivity, v4 would work as well). > >>> > >>> If this > >>> > >>> > >>>>would imply that the communication between two nodes > inside the 3GPP > >>>>network or communication originating from IPv6 internet and > >> > >>coming to > >> > >>>>a 3GPP node could just silently fail.. this would seem to be very > >>>>undesirable. > >>> > >>> > >>>Note this is not about the connectivity silently failing, it > >>>is about the node no longer being there/no longer being active. > >>> > >>>But what you're saying is that the destination unreachable > >> > >>ICMPs are a MUST > >> > >>>to support at a Ipv6-in-Ipv4 Tunnel Server ? > >>> > >>>- BTW, with the risk of bluring the difference in between > >>>solution space and requirement space - I suppose this in > >> > >>particular applies > >> > >>>to the v6ops accepted "tunnel server" mechanisms, 6to4 and > >> > >>Teredo border routers ? > >> > >>> > >>>>-- > >>>>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 Wed Sep 15 08:50:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29317 for ; Wed, 15 Sep 2004 08:50:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C7ZDl-0008Co-Fb for v6ops-data@psg.com; Wed, 15 Sep 2004 12:49:13 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C7ZDC-00089I-A1 for v6ops@ops.ietf.org; Wed, 15 Sep 2004 12:48:38 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I430050727NAQ@mailout3.samsung.com> for v6ops@ops.ietf.org; Wed, 15 Sep 2004 21:47:47 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I43009VT27NLK@mailout3.samsung.com> for v6ops@ops.ietf.org; Wed, 15 Sep 2004 21:47:47 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I4300LGX27LWB@mmp2.samsung.com> for v6ops@ops.ietf.org; Wed, 15 Sep 2004 21:47:47 +0900 (KST) Date: Wed, 15 Sep 2004 18:17:08 +0530 From: Radhakrishnan Suryanarayanan Subject: Re: Unreachability detection at tunnels servers WAS: RE: Comments onzeroconf draft To: "Karen E. Nielsen (AH/TED)" , "'Brian E Carpenter'" Cc: "'Pekka Savola'" , V6OPS WG , juha.wiljakka@nokia.com, "'Jeroen Massar'" Reply-to: Radhakrishnan Suryanarayanan Message-id: <0a6001c49b22$1dbd8710$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I think pekka and other members of WG must provide their opinion to your question. ----- Original Message ----- From: "Karen E. Nielsen (AH/TED)" To: "'Radhakrishnan Suryanarayanan'" ; "'Brian E Carpenter'" Cc: "'Pekka Savola'" ; "V6OPS WG" ; ; "'Jeroen Massar'" Sent: Wednesday, September 15, 2004 1:37 PM Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments onzeroconf draft > Hi Radhakrisnan, > > [snip] > > > > If IPv6 NUD is also supported then we can either translate > > the ICMPv4 error > > messages (faster) or cache out the NUD entry if address > > resolution fails. > > Note that I am talking about RFC 2461 "NUD-like" mechanism, as > RFC 2461 NUD is based on the fact that address resolution gives proof > of reachability. This may not be the case on the tunnel links, e.g. in > Teredo, 6to4 and Isatap, where address resolution in itself may > not provide proof of reachability. > > > The tunnel server must support "packet too big" translation > > anyway for IPv6 > > PMTU. so as well have a couple of other error messages > > translated as well > > which can be helpful. > > > > IMHO, ICMPv4 error message translation & IPv6 NUD both should > > be supported. > > > > OK, that's clear talk. Thanks. > > I am still looking for the general sentiment in the WG > on this, though. > > Any opinions ? > > BR, Karen > > > Regards > > Radhakrishnan > > > > From owner-v6ops@ops.ietf.org Wed Sep 15 09:13:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01399 for ; Wed, 15 Sep 2004 09:13:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C7ZaP-000BgK-0y for v6ops-data@psg.com; Wed, 15 Sep 2004 13:12:37 +0000 Received: from [202.103.147.144] (helo=zte.com.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1C7ZZD-000BVp-LW for v6ops@ops.ietf.org; Wed, 15 Sep 2004 13:11:37 +0000 Received: from [10.30.1.239] by 10.30.2.249 with StormMail ESMTP id 41580.169246066; Wed, 15 Sep 2004 21:09:02 +0800 (CST) In-Reply-To: <1095057557.2608.283.camel@segesta.zurich.ibm.com> To: v6ops@ops.ietf.org Subject: Re: Which IPv6 Option Types are reserved for testing? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: luo.chao@zte.com.cn Date: Wed, 15 Sep 2004 21:17:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.10 |March 22, 2002) at 2004-09-15 21:14:41, Serialize complete at 2004-09-15 21:14:41 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_DOUBLE_IP_SPAM autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Why don't people pay attention to this topic? I do consider it a limitation of current specs. Regards, LC Jeroen Massar wrote: >Hi, > >I am currently extending AYIYA to do proper multihoming. >As I intend to do wider-scale testing, outside of the very small test >setup I am currently using, I was wondering what Option Types are >reserved or can be used for this kind of testing. Because, just like the >206 ICMPv6 option for MLDv2, changing it after it has been circulated >quite a bit can be a bit painful, indeed it is a part of the kernel. >Reading: http://www.iana.org/assignments/ipv6-parameters > >It apparently contains no reserved ones. Typically it would need a: > >act chg rest >--- --- ----- > 11 0 xxxxx AYIYA Option Header > >But what can I use for the last 5 bits? >Exact contents of this header will come in the next update, -03 version >of the AYIYA draft, which will also describe how it is used and > >I could of course fill in a general request form at IANA but then they >will probably say that you need an RFC and bladiebla... while I just >want to let people test it first ;) You need implementations of a thing >anyway before it can become an rfc usually, this there is a small loop >there. > >Greets, > Jeroen > >PS: Yes, draft-ietf-multi6-things-to-think-about questions are answered >positively and no dependency on DNS etc ;) ******************************************* 本邮件已ç»è¿‡åžƒåœ¾é‚®ä»¶è¿‡æ»¤ï¼Œå¦‚å‘现垃圾 邮件，请转å‘至：helpdesk@zte.com.cn ******************************************* From owner-v6ops@ops.ietf.org Thu Sep 16 15:43:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09554 for ; Thu, 16 Sep 2004 15:43:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C826i-000FqT-7F for v6ops-data@psg.com; Thu, 16 Sep 2004 19:39:52 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C826X-000FoT-BQ for v6ops@ops.ietf.org; Thu, 16 Sep 2004 19:39:41 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09279; Thu, 16 Sep 2004 15:39:36 -0400 (EDT) Message-Id: <200409161939.PAA09279@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-analysis-00.txt Date: Thu, 16 Sep 2004 15:39:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 Enterprise Network Analysis Author(s) : J. Bound, et al. Filename : draft-ietf-v6ops-ent-analysis-00.txt Pages : 30 Date : 2004-9-16 This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition units and requirements expanded from a previous Enterprise Scenarios document, and will depict a set of components and transition methods required for the enterprise to transition to IPv6 within each scenario and then common to all scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-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-ent-analysis-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-ent-analysis-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. --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: <2004-9-16155108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-16155108.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Sep 17 07:40:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26950 for ; Fri, 17 Sep 2004 07:40:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C8H48-0005Ff-Eb for v6ops-data@psg.com; Fri, 17 Sep 2004 11:38:12 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C8H3w-0005ET-Vw for v6ops@ops.ietf.org; Fri, 17 Sep 2004 11:38:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8HBbv102349 for ; Fri, 17 Sep 2004 14:37:57 +0300 Date: Fri, 17 Sep 2004 14:37:57 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-mech-v2-06 and TTL when encapsulating Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) A couple of IESG people felt a bit unfortable with draft-ietf-v6ops-mech-v2-06.txt, the paragraph about which TTL to use when encapsulating (section 3.2). Now it says: The TTL of the encapsulating IPv4 header is selected in an implementation dependent manner. The current suggested value is published in the "Assigned Numbers" RFC [RFC3232][ASSIGNED]. The implementations MAY also consider using the value 255. Implementations MAY provide a mechanism to allow the administrator to configure the IPv4 TTL as the IP Tunnel MIB [RFC2667]. At least, they argued that the sentence about TTL=255 should be removed. One also argued that the whole paragraph is unnecessary, because there should be nothing tunneling-specific here. (However, there are a number of implementations which allow specifying the TTL for just tunneling, so at least there are implementations..) The TTL=255 suggestion is useful because it can be rather reliably be used to figure out how many hops the particular tunnel packet has traversed. Do WG participants have opinions about this? 1) (try to) convince the IESG to keep it as is 2) remove the TTL=255 suggestion 3) remove everything or almost everything 4) rewrite the paragraph (suggestions are welcome) 5) something else, what? Off-list reply is also fine. (hat off) -- 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 Sat Sep 18 14:29:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07814 for ; Sat, 18 Sep 2004 14:29:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C8jt8-00081Z-3S for v6ops-data@psg.com; Sat, 18 Sep 2004 18:24:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C8jsw-00080y-Q5 for v6ops@ops.ietf.org; Sat, 18 Sep 2004 18:24:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8IIOWH08227 for ; Sat, 18 Sep 2004 21:24:32 +0300 Date: Sat, 18 Sep 2004 21:24:32 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt In-Reply-To: <200409161939.PAA09279@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) This is the initial draft on Enterprise network analysis, and is still being improved. We need input from the WG to make it better. Please read and comment ASAP, preferably within a week. We hope to get this in the shape for WG last call reasonably soon. Again, please send feedback. This is very important work! (hat off) On Thu, 16 Sep 2004 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 Enterprise Network Analysis > Author(s) : J. Bound, et al. > Filename : draft-ietf-v6ops-ent-analysis-00.txt > Pages : 30 > Date : 2004-9-16 > > This document analyzes the transition to IPv6 in enterprise > networks. These networks are characterized as a network that has > multiple internal links, one or more router connections, to one or > more Providers, and is managed by a network operations entity. The > analysis will focus on a base set of transition units and > requirements expanded from a previous Enterprise Scenarios > document, and will depict a set of components and transition > methods required for the enterprise to transition to IPv6 within > each scenario and then common to all scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-00.txt [...] From owner-v6ops@ops.ietf.org Sun Sep 19 07:31:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10333 for ; Sun, 19 Sep 2004 07:31:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C8zsa-000HFM-Bs for v6ops-data@psg.com; Sun, 19 Sep 2004 11:29:16 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C8zsO-000HEJ-6B for v6ops@ops.ietf.org; Sun, 19 Sep 2004 11:29:05 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 8B087800D; Sun, 19 Sep 2004 13:28:57 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 00714-60; Sun, 19 Sep 2004 13:28:51 +0200 (CEST) Received: from [9.4.69.192] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E73D47F68; Sun, 19 Sep 2004 13:28:50 +0200 (CEST) Subject: New Ghost Route Hunter Utility: Prefix Compare From: Jeroen Massar Reply-To: jeroen@sixxs.net To: 6bone@isi.edu, ipv6-wg@ripe.net, v6ops@ops.ietf.org Cc: info@sixxs.net Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IffZRwrenrKf7oCHD7QH" Organization: Unfix Message-Id: <1095593327.1978.8395.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 19 Sep 2004 13:28:48 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-IffZRwrenrKf7oCHD7QH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Always wonder what was wrong with a prefix? Wondering which ISP's are not able to reach you and where it stops? GRH (Ghost Router Hunter *1) now has a new utility for doing prefix comparisons (*2). This feature was requested by Daniel R=C3=B6sen for the purpose of comparin= g: 2001:5000::/21 with 2001:650::/32 (*3). Which are originated from the same ASN, but as the /21 is filtered at some places, have different or no paths to the participants (*4) that provide routes to GRH and many more ISP"s around the world. This utility thus allows you to see which participants of GRH do have the routes in question and the difference in the paths towards those participants. This allows a very quick view where a prefix is not accepted, most possibly of misconfigured filters. People who don't have, for instance, 2001:5000::/21 in their BGP, please figure out where the filtering is wrongly applied by looking at the utility and applying the current set of recommended filters, available from: http://www.space.net/~gert/RIPE/ipv6-filters.html It is good to see that ISP's have prefix filtering, but they really should update them. Though I'd rather see no prefix filtering but that they do RPF filtering on their customers. When you have (near) 0 IPv6 prefixes in your BGP, then you better start catching on ;) At the moment of writing you should have at least IPv6 499 prefixes, as then you have all the allocated, and currently announced, TLA's in your router, if you have less you are missing a number of them. For interested ISP's, GRH signup is, of course, free and can be done through the website (*5), the more peers join, the better the statistics of all the GRH utilities will be. Also, if you, like Daniel, miss a good utility, don't hesitate to bring it up. I would also like to thank all the already participating ISP's for providing their tables which have made it able to fix a large number of problems already over the almost 2 years GRH has been running. Last but not least, thanks to Daniel R=C3=B6sen for the brilliant idea. Greets, Jeroen *1 =3D http://www.sixxs.net/tools/grh/ *2 =3D http://www.sixxs.net/tools/grh/compare/ *3 =3D http://www.sixxs.net/tools/grh/compare/?a=3D2001:5000::/21&b=3D2001:650::/3= 2 *4 =3D http://www.sixxs.net/tools/grh/participants/ *5 =3D http://www.sixxs.net/tools/grh/signup/ --=-IffZRwrenrKf7oCHD7QH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBTW1vKaooUjM+fCMRAq7MAJ4/i8xpqu4YIb2xxWLBz948qlXKEgCeP8ml SL3oSR1pbhdcEcuF61ZHc/I= =qp6J -----END PGP SIGNATURE----- --=-IffZRwrenrKf7oCHD7QH-- From owner-v6ops@ops.ietf.org Sun Sep 19 07:47:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11254 for ; Sun, 19 Sep 2004 07:47:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C9098-000JBz-D5 for v6ops-data@psg.com; Sun, 19 Sep 2004 11:46:22 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C908x-000JAf-OC for v6ops@ops.ietf.org; Sun, 19 Sep 2004 11:46:11 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id i8JBkAWi002245; Sun, 19 Sep 2004 11:46:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id i8JBkAGs002242; Sun, 19 Sep 2004 11:46:10 GMT Date: Sun, 19 Sep 2004 11:46:10 +0000 From: bmanning@vacation.karoshi.com To: jeroen@sixxs.net Cc: 6bone@isi.edu, ipv6-wg@ripe.net, v6ops@ops.ietf.org, info@sixxs.net Subject: Re: New Ghost Route Hunter Utility: Prefix Compare Message-ID: <20040919114610.GD2190@vacation.karoshi.com.> References: <1095593327.1978.8395.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1095593327.1978.8395.camel@firenze.zurich.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > Always wonder what was wrong with a prefix? Thanks for the great tool. I can now see which ASNs are proxy-aggregating my prefixes w/o authorization/permission. :) > It is good to see that ISP's have prefix filtering, but they really > should update them. Though I'd rather see no prefix filtering but that > they do RPF filtering on their customers. ... prefix filtering ought to reflect the desires of the authentic origin AS... :) > > I would also like to thank all the already participating ISP's for > providing their tables which have made it able to fix a large number of > problems already over the almost 2 years GRH has been running. > Last but not least, thanks to Daniel Rösen for the brilliant idea. > > Greets, > Jeroen > > *1 = http://www.sixxs.net/tools/grh/ > *2 = http://www.sixxs.net/tools/grh/compare/ > *3 = > http://www.sixxs.net/tools/grh/compare/?a=2001:5000::/21&b=2001:650::/32 > *4 = http://www.sixxs.net/tools/grh/participants/ > *5 = http://www.sixxs.net/tools/grh/signup/ > From owner-v6ops@ops.ietf.org Tue Sep 21 00:08:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23161 for ; Tue, 21 Sep 2004 00:08:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1C9brg-000Prd-VA for v6ops-data@psg.com; Tue, 21 Sep 2004 04:02:52 +0000 Received: from [202.186.110.22] (helo=ampang.nottingham.edu.my) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1C9ZeI-0006VL-Hz for v6ops@ops.ietf.org; Tue, 21 Sep 2004 01:40:54 +0000 Received: from klw0f.nottingham.edu.my ([202.186.110.20] helo=gwmail.nottingham.edu.my) by ampang.nottingham.edu.my with esmtp (Exim 3.34 #1) id 1C9ZeG-0003BK-00 for v6ops@ops.ietf.org; Tue, 21 Sep 2004 09:40:52 +0800 Received: from gwmail-MTA by gwmail.nottingham.edu.my with Novell_GroupWise; Tue, 21 Sep 2004 09:40:40 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Tue, 21 Sep 2004 09:40:35 +0800 From: "Edwin Kit Keong Ng" To: <6bone@ISI.EDU>, , , Cc: Subject: Converting IPv4 devices to IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all... Can anyone please help me. I am in the middle of a project with the objective of enhancing the current Routers, including Home Agent and the Foreign Agent. This is in a Wireless environment focusing on Mobile IP. If i would like to convert the hardware devices to an IPv6 enabled device, what are the steps i have to take? Thank you. Regards, Edwin Ng From owner-v6ops@ops.ietf.org Wed Sep 22 03:02:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07643 for ; Wed, 22 Sep 2004 03:02:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CA15x-000K99-0d for v6ops-data@psg.com; Wed, 22 Sep 2004 06:59:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CA15k-000K7L-KF for v6ops@ops.ietf.org; Wed, 22 Sep 2004 06:59:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8M6wnq30391; Wed, 22 Sep 2004 09:58:49 +0300 Date: Wed, 22 Sep 2004 09:58:49 +0300 (EEST) From: Pekka Savola To: Adeel Ahmed cc: Ciprian Popoviciu , , Salman Asadullah , Patrick Grossetete Subject: Re: Draft on ISP broad-band deployment scenarios In-Reply-To: <4.3.2.7.2.20040910170906.0173e1e8@cactus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Sorry for not getting back to this earlier :-(.. inline.. On Fri, 10 Sep 2004, Adeel Ahmed wrote: > Please see my responses inline with +++++++++++++++: > > At 02:43 PM 9/7/2004 +0300, Pekka Savola wrote: > >Sorry for the delay in responding.. inline... > > > >(I've removed some comments which we seemed to agree or be clear > >about.) > > > >On Wed, 1 Sep 2004, Ciprian Popoviciu wrote: > > > >On Thu, 19 Aug 2004, Pekka Savola wrote: > > > > > Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a > > > > > lot of work in a very short time and produced a really extensive > > > > > scenarios document discussing the IPv6 deployment scenarios for > > > > > broadband (DSL, cable, etc.). > > > > > > > >A couple of general observations: > > > > > > > > 0) is the document aiming to only describe the scenarios, or is the > > > >goal to also provide analysis where potential gaps have been > > > >identified, and where e.g., a tunneling mechanism would be needed? If > > > >the latter, it probably needs to be expanded a bit. > > > > > > @@@ > > > Pekka, to put this document in perspective, here are some elements of our > > > original intent: > > > - focus on production type deployments. We did not intend to discuss > > tunneling > > > unless it is the only alternative currently available due to > > limitations of > > > a given access > > > technology (cable). > > > >OK, though I'm not sure how certain types of tunneling solutions could > >not be considered "production" (or sufficiently near that) to be > >useful on a larger scale. The justification for that is that there > >may be lots of equipment that is not IPv6-capable, and having to wait > >for it to be replaced to be able to offer (or get) IPv6 connectivity > >may be a big assumption for deployment. > > > +++++++++++++++ > Our goal in this draft is to get SPs to move towards deployment of > native IPv6. So leading to such deployments tunneling would be a > stepping stone for the SPs. However, considering that there are > native deployments today, we wanted to focus more on them rather > then on the transitional phase in which it might be rather difficult > for an SP to generate revenue from a tunnel based service till they > move towards native IPv6 deployments. There are native deployments today, but AFAIK they have been relatively small scale (thousands of users). The crux is whether the ISP wants to (try to) offer service to *all* of its customers, requiring no hardware upgrades or purchases, with no assumptions about what the user has deployed -- or just those which are OK the assumptions, upgrades/purchases, etc. I'm concerned that if we focus too much on "native only", only (relatively) few users will likely be able to get the service. It's true that it may be difficult for an ISP to generate revenue out of e.g., tunneling based service, offered to anyone, but if some ISP's are still interested in this kind of approach, would it be worth considering? > In the case of Cable (section 5) we had to talk about tunnels due to > the current limitations in DOCSIS but all the other access > technologies discussed in the draft are ready for native IPv6 > deployment today. > +++++++++++++++ The approach depends on the ISP's strategy. If it wants to offer services to just those which have the right kind of set-up, no interfering NAT boxes, their own wireless routers, or whatever, that's fine. But I'm quite concerned about making such assumptions, because in practice that implies that the deployment gets much more difficult and demanding (also due to need for financial justifications) for the users. > >The question I was asking was whether you intended to analyze the > >applicability of different methods for getting IPv6 connectivity (in > >case there would be multiple: for example, where you cite 6to4, there > >could very likely be others as well, possibly even more suitable than > >that), or just pick one (or none) and describe how that would work. > >In other words, I was interested whether you were considering > >"generic" deployment (with as few assumptions as reasonable, about, > >e.g., equipment at the customer's premises), or "specific" deployment > >(where you could or could not assume some things, like being able to > >upgrade a certain box or having public IPv4 addresses). > > > >The document would certainly seem to be most useful if it was > >sufficiently "generic", but a "specific" document is also better than > >nothing ;-), provided that the assumptions are very clearly spelled > >out. > > +++++++++++++++ > We've actually tried to be specific in sections 6,7 & 8. We've used > kind of a generic approach in section 5 due to the current state of > cable networks and the limitations in DOCSIS. We will try to spell > out some of the assumptions more clearly in our next revision of the > draft. > +++++++++++++++ OK. Please also state clearly the caveats of "native only, if technologically possible" approach (discussed above, for example). > > > > 2) the document seems to make some assumptions e.g., when it > > specifies to > > > >use 6to4 e.g., for cable. Are all of the networks using public v4 > > > >addresses? What if the customer has deployed a NAT box so that the public > > > >address is consumed by that box? Further, I'm not sure whether the > > > >situation where the customer has deployed some equipment has been > > considered > > > >throughout the document. > > > > > > @@@ > > > Again, it is a case very specific to the current state of Cable > > > access. > > > >Do you mean that cable operators are widely offering a public IP > >address per customer? However, I'd venture to guess there are a > >significant number of operators which only give private addresses to > >begin with. > > +++++++++++++++ > Actually that is a common practice with most Cable > Operators. We've worked with major Cable providers in the America, > EMEA and APAC regions and they all offer public IP addresses to > their customers. > +++++++++++++++ OK, please make this assumption and justification explicit in the document. > > > Nevertheless we could probably offer more detail for this > > > case. For example, one solution would be to have the box that is > > > doing the NAT for the user also terminate the tunnel. > > > > > > This is another point that we need to clarify however, the Gateway > > > Router (GWR) can be SP owned but also it can be customer owned and > > > in that case it would reflect a customer deployed equipment like a > > > box that does NAT for v4. > > > @@@ > > > >Exactly, this cuts both ways: one approach could be to assume that the > >NAT box (which may be beyond the control of the SP) is upgraded -- > >this could take quite a long time to achieve. Another approach could > >be to provide mechanisms which work irrespective of NATs -- there are > >already a plenty of those, for example Teredo, and some others > >probably to come (think of "configured tunneling over UDP with > >keepalives"), in one form or the other. > > > >I think what you were assuming that you only need to care about the > >case of upgrading the NAT box. That may be acceptable with certain > >assumptions about the deployment (if that's the case, they must be > >very clearly spelled out), but it may not be sufficient in more > >general -- so if you agree that one would want to provide v6 access > >also when there are NATs or other obstacles in the way, one such > >approach is to specify v6 connectivity mechanissm which work through a > >NAT. > > +++++++++++++++ > That's a good point, we will make a note of that in section 5 where we > discuss initiating a tunnel from > the host. Since our goal is to provide IPv6 access natively this should not > be an issue for other technologies. > +++++++++++++++ OK. > > > @@@ > > > These are deployment issues that we could elaborate a bit more on. The > > > provider usually > > > is not responsible for the additional equipment added by the customer and > > > under the > > > constraints of a service deployment that is limited by the current > > state of > > > DOCSIS it is likely that > > > the provider will have to provide a new device to the subscriber. We will > > > add a note on this > > > topic. > > > @@@ > > > >This is one approach, as noted at the start of the message; another is > >providing tunneling support. Both could be feasible, depending on > >deployment, but the latter is more generic at least. > > +++++++++++++++ > Right, so cable operators currently do provide a GWR which is managed by > them. In order > to deploy IPv6 the operator can upgrade or replace this GWR with a v6 > capable device. > +++++++++++++++ Right. But my practical concern is that if it costs the ISP XXX XXX $ to replace the GWR's with ipv6-supporting versions, but XXXX $ (XXX XXX >> XXXX) to provide tunneling support, I'd guess most ISPs would be interested in going for tunneling first, and just looking at replacing GWR's based on their natural EOL schedule. > >OK -- I'm just having trouble visualizing any ISP doing so, because > >that might directly jeopardize their IGP to the customers.. and I'd be > >interested in hearing why they would be doing something like this (is > >this some kind of backup routing plan for some SOHO customers or the > >like or what). > > +++++++++++++++ > This is currently a normal practice for Cable Operator's business customers. > There are only a handful of these customer routes which are summarized and > redistributed into the Cable Operator's IGP. This is not really meant for > residential > customers which account for majority of the customer base. > +++++++++++++++ But what I don't understand is why the business customers would 1) need dynamic routing in the first place (what is the actual reason for using a routing protocol?), and 2) would want to use something as "unreliable" (with some definition of unreliable) as Cable, instead of DSL, Serial, Ethernet. > > > >6.2.1 POINT-TO-POINT MODEL > > > > > > > > > > > >==> this model has the built-in assumption that ATM is used as > > > >point-to-point. Is this strictly necessary, or could you just use any > > other > > > >media as well? > > > > > > @@@ > > > Could you please clarify this comment? > > > @@@ > > > >I meant that wouldn't it be possible to use e.g., Ethernet (instead of > >ATM) as the point-to-point uplink? I haven't seen this myself, but > >I've heard reports of such deployments.. > > +++++++++++++++ > We've discussed this in the FTTH section 7.2.1. So we did not really assume > that only ATM will be used as a point-to-point uplink. > +++++++++++++++ But couldn't you provide ADSL (instead of FTTH or Ethernet to the home) using Ethernet or something like HomePNA on the uplink instead of ATM? I don't know enough of the deployments to be able to say whether "ADSL with Ethernet-like uplink" and "FTTH" are synonymous, but if I had to venture a guess, I'd say there's probably some difference there. > > > @@@ > > > Why would you see it as a bad practice having the router acquire via > > stateless > > > autoconfig an address for the uplink to the provider? We should probably > > > discuss > > > all options for completeness purposes. > > > @@@ > > > >Well, if you have a router, I'd generally expect it to act as a router > >on all of its interfaces. There has been some debate of this mixed > >"host/router" behaviour on IPv6 WG list before, but I think the > >conclusion has been that mixed host/router is acceptable by the specs > >at least. I'd however personally rather see that the routers in these > >situations would have other means to configure an address (if they > >need one). > > +++++++++++++++ > We've seen customer interest in using this approach for IPv6 therefore we > discuss it in the draft. > Similar approach is also available in IPv4. > +++++++++++++++ Please state explicitly that this is takes a mixed host/router approach to ND. > >These arguments should maybe go in the draft, but still keep in mind > >that MLD/IGMP have not been meant to authenticate the users. > > > >I'd expect that the same features can be obtained with encrypted data. > >You would get the key which would be valid only for some time from a > >web server, and that key would be only valid for a certain stream. > >That way you could get the keys etc. only only those parts of the > >transmission you'd want. There are possibly other approaches. MSEC > >(http://www.ietf.org/html.charters/msec-charter.html) WG has been > >looking at this problem. > > +++++++++++++++ > We do realize that there are multiple ways of doing this but we went with > MLD authentication approach because we have seen requirements for this > from customers and it's a rather simple approach. > > But we will try to add more explanation in the next revision of the draft. > +++++++++++++++ Thanks. Justification and listing the caveats is good. -- 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 Wed Sep 22 03:13:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08244 for ; Wed, 22 Sep 2004 03:13:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CA1J1-000MCc-Es for v6ops-data@psg.com; Wed, 22 Sep 2004 07:12:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CA1Iq-000MBn-Gj for v6ops@ops.ietf.org; Wed, 22 Sep 2004 07:12:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8M7CTX30769; Wed, 22 Sep 2004 10:12:32 +0300 Date: Wed, 22 Sep 2004 10:12:29 +0300 (EEST) From: Pekka Savola To: Jeroen Massar cc: v6ops@ops.ietf.org Subject: Re: Which IPv6 Option Types are reserved for testing? In-Reply-To: <1095057557.2608.283.camel@segesta.zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (sorry for delay) [personal response, without any hats, obviously] On Mon, 13 Sep 2004, Jeroen Massar wrote: > I am currently extending AYIYA to do proper multihoming. > As I intend to do wider-scale testing, outside of the very small test > setup I am currently using, I was wondering what Option Types are > reserved or can be used for this kind of testing. Because, just like the > 206 ICMPv6 option for MLDv2, changing it after it has been circulated > quite a bit can be a bit painful, indeed it is a part of the kernel. > Reading: http://www.iana.org/assignments/ipv6-parameters > > It apparently contains no reserved ones. Typically it would need a: > > act chg rest > --- --- ----- > 11 0 xxxxx AYIYA Option Header > > But what can I use for the last 5 bits? > Exact contents of this header will come in the next update, -03 version > of the AYIYA draft, which will also describe how it is used and > > I could of course fill in a general request form at IANA but then they > will probably say that you need an RFC and bladiebla... while I just > want to let people test it first ;) You need implementations of a thing > anyway before it can become an rfc usually, this there is a small loop > there. Unfortunately, the IPv6 specs have provided no IANA assignment policy, so it's unclear which one it is.. but at least one person has obtained a value without significant documentation, so I guess it might be possible to get an assignment even without RFC. RFC3692 ("Assigning Experimental and Testing Numbers Considered Useful") discusses this, but it doesn't help in this case, as an experimental number space has not been set up. I fear I cannot help with this except by stating that there might a couple of options: 1) just pick [illegitimately] a codepoint value for now, or use the one used for "endpoint identification", which has probably been dead for the last 5 years. 2) redesign the protocol to use something else than IP options. In many cases the IP options are a bad way to go in any case. 3) bring up the issue in IPv6 WG, asking the WG to produce a document which: 1) appropriately documents the IANA assignment policies for IANA IPv6 registries [this is IMHO pretty important], and 2) specifies an experimental code point values these IANA codepoints. 4) just try to send in a request for the value and see what happens. 5) take this as a good opportunity to provide feedback on draft-narten-iana-considerations-rfc2434bis-01.txt, which discusses the IANA assignment policies, whether this is something that needs to be covered better (and if so, how?). I'd recommend you'd do at least 3), but if you don't, I'll have to bring this up again, I guess. If I were you, I'd also consider whether 2) is a viable option. -- 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 Wed Sep 22 03:49:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10417 for ; Wed, 22 Sep 2004 03:49:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CA1rc-0000eI-Sk for v6ops-data@psg.com; Wed, 22 Sep 2004 07:48:32 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CA1rR-0000Zw-PJ for v6ops@ops.ietf.org; Wed, 22 Sep 2004 07:48:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8M7mIb31549; Wed, 22 Sep 2004 10:48:18 +0300 Date: Wed, 22 Sep 2004 10:48:18 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: V6OPS WG , "'Radhakrishnan Suryanarayanan'" , , "'Soininen Jonne (Nokia-NET/Helsinki)'" Subject: Re: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I'm not sure if there was a conclusion/resolution to this thread. As for my personal take -- hopefully I've understood the arguments properly.. If you receive IPv4 ICMP error messages relating to an IPv6-in-IPv4 tunnel, one should probably do something if it's possible, because that will be an indication that IPv6 link layer has failed (and that particular error can be propagated the same way as any other IPv6 link failure, or by direct ICMP message conversion). What and whether the implementations must treat IPv4 ICMP error messages somehow depends on the mechanism in question. draft-ietf-v6ops-mech-v2-06.txt does not mandate it for static MTU discovery, but it's obviously required for dynamic MTU discovery. 6to4 spec (section 7) doesn't require it either, but seems to imply that it can be done. So, as to the issue whether tunnel servers need to be able to send back ICMPv6 error messages if the implementation thinks that the link has failed, I'd say "yes, it probably should" because shouldn't all IPv6 nodes be supposed to be able to do something like that. The issue then is what constitutes good indication for "link failure" (e.g., in this case, IPv4 tunneling failing). Specifying what that must or should include is probably mechanism-dependent. On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > An issue of general character has been brought up in connection with the zero-conf work. > The issue is the following: > > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support NUD-like mechanisms that enables > them to send ICMP destination unreachable messages back to origin ? > > The initial feedback received in this respect is that - "yes, they MUST". > > As some RFCs previously has been silent about this, e.g. 6to4 - RFC 3056, > and the working group currently is standardising a mechanism which also seems > to be silent about this (Teredo) I would very much like to hear if the above is the > general sentiment of the work group. > > I should be stressed that adding this to the goals of the zero-conf requirements > document isn't believed to severely limit the solution space - but it requires > implementation of a mechanism which is know to scale very badly and > which in addition is susceptible to the DoS attack described in Section 4.3.2 of RFC 3756. > > BR, Karen > > > > > > > On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > > > Normally last hops routers performs NUD so that they can send ICMPs > > > back to origin to notify of black holes/unreachability. Personally > > > I am not sure that this is a MUST requirement on the Tunnel Servers. > > > I have actually thought that we could avoid this, especially since > > > we have no explicit goals as to the nodes being registered as > > > reachable in the DNS using the Ipv6 address - wherefore we are first > > > and foremost looking to support the situation where communication is > > > initiated by the tunnel clients and not from the outside. > > > > This seems short-sighted to me, because the actual *advantage* of IPv6 > > is realized only when *incoming* connectivity is enabled (if it was > > just about outbound connectivity, v4 would work as well). > If this > > would imply that the communication between two nodes inside the 3GPP > > network or communication originating from IPv6 internet and coming to > > a 3GPP node could just silently fail.. this would seem to be very > > undesirable. > > Note this is not about the connectivity silently failing, it > is about the node no longer being there/no longer being active. > > But what you're saying is that the destination unreachable ICMPs are a MUST > to support at a Ipv6-in-Ipv4 Tunnel Server ? > > - BTW, with the risk of bluring the difference in between > solution space and requirement space - I suppose this in particular applies > to the v6ops accepted "tunnel server" mechanisms, 6to4 and Teredo border routers ? > > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > -- 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 Wed Sep 22 03:53:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10828 for ; Wed, 22 Sep 2004 03:53:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CA1wI-0001Rl-SA for v6ops-data@psg.com; Wed, 22 Sep 2004 07:53:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CA1w7-0001Ph-Vw for v6ops@ops.ietf.org; Wed, 22 Sep 2004 07:53:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8M7rAA31766 for ; Wed, 22 Sep 2004 10:53:10 +0300 Date: Wed, 22 Sep 2004 10:53:10 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-mech-v2-06 and typo in 3.2.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) When browsing draft-ietf-v6ops-mech-v2-06.txt I noticed the following text in section 3.2.1: The selection of a good tunnel MTU depends on many factors; at least: - Whether the IPv4 protocol-41 packets will be transported over media which may have a lower path MTU (e.g., IPv4 Virtual Private Networks); then picking too high a value might lead to IPv4 fragmentation. - Whether the tunnel is used to transport IPv6 tunneled packets (e.g., a mobile node with an IPv4-in-IPv6 configured tunnel, and an IPv6-in-IPv6 tunnel interface); then picking too low a value might lead to IPv6 fragmentation. .. I believe there is a typo there, s/IPv4-in-IPv6/IPv6-in-IPv4/ (because otherwise there wouldn't be layered encapsulation related to this spec :). If you disagree, please comment off-list. (hat off) -- 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 Wed Sep 22 04:14:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12222 for ; Wed, 22 Sep 2004 04:14:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CA2F6-0004Ui-8c for v6ops-data@psg.com; Wed, 22 Sep 2004 08:12:48 +0000 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CA2Em-0004Qk-0z for v6ops@ops.ietf.org; Wed, 22 Sep 2004 08:12:29 +0000 Received: from zctfc006.europe.nortel.com (zctfc006.europe.nortel.com [47.164.129.47]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8M8COE10932 for ; Wed, 22 Sep 2004 10:12:24 +0200 (MEST) Received: from zctfc004.europe.nortel.com ([47.164.129.45]) by zctfc006.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TH4S62ND; Wed, 22 Sep 2004 10:12:24 +0200 Received: from [192.168.201.6] (actft029.europe.nortel.com [47.164.193.66]) by zctfc004.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TH4P3YH1; Wed, 22 Sep 2004 10:12:23 +0200 User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Wed, 22 Sep 2004 10:12:18 +0200 Subject: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt X-Sybari-Trust: e4716c4d d27f880e 34639fb9 00000104 From: "Cedric Aoun" To: V6OPS CC: "Elwyn Davies" Message-ID: In-Reply-To: <200409211938.PAA14143@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3178692742_3596938" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3178692742_3596938 Content-type: multipart/alternative; boundary="B_3178692742_3585648" --B_3178692742_3585648 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, As discussed at IETF 60, the WG agreed to continue the NAT-PT deprecation analysis. We would really appreciate if you could provide us your feedback on the initial version of the deprecation analysis by Monday October 4th. Regards Cedric Aoun > ------ Forwarded Message > From: > Reply-To: > Date: Tue, 21 Sep 2004 21:38:33 +0200 > To: > Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Reasons to Deprecate NAT-PT > Author(s) : C. Aoun, E. Davies > Filename : draft-aoun-v6ops-natpt-deprecate-00.txt > Pages : 24 > Date : 2004-9-21 > > This document discusses reasons why use of the specific form of > IPv6-IPv4 protocol translation mechanism implemented by the Network > Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766 > should be deprecated and RFC2766 moved to historic status. > Description of an alternative protocol translation mechanism is out > of scope for this document. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprecate-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-aoun-v6ops-natpt-deprecate-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-aoun-v6ops-natpt-deprecate-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. > > > ------ End of Forwarded Message --B_3178692742_3585648 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Hi, As discussed at IETF 60, the WG agreed to continue the NAT-PT deprecation a= nalysis.
We would really appreciate if you could provide us your feedback on the ini= tial version of the deprecation analysis by Monday October 4th.
Regards
Cedric Aoun

------ Forwarded Message
From: <Internet-Drafts@ietf.org>
Reply-To: <internet-drafts@ietf.org>
Date: Tue, 21 Sep 2004 21:38:33 +0200
To: <i-d-announce@ietf.org>
Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt


A New Internet-Draft is available from the on-line Inte= rnet-Drafts directories.


        Title    &nb= sp;      : Reasons to Deprecate NAT-PT
        Author(s)    = ;   : C. Aoun, E. Davies
        Filename    =     : draft-aoun-v6ops-natpt-deprecate-00.txt
        Pages    &nb= sp;      : 24
        Date    &nbs= p;       : 2004-9-21
        
This document discusses reasons why use of the specific form of
   IPv6-IPv4 protocol translation mechanism implemented by t= he Network
   Address Translator - Protocol Translator (NAT-PT) defined= in RFC 2766
   should be deprecated and RFC2766 moved to historic status= .
   Description of an alternative protocol translation mechan= ism is out
   of scope for this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprec= ate-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 usernam= e
"anonymous" and a password of your e-mail address. After logging = in,
type "cd internet-drafts" and then
        "get draft-aoun-v6ops-= natpt-deprecate-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/i= etf/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-aoun-v6ops-natpt-deprecate-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 th= e response(s), you will need "munpack" or
        a MIME-compliant mail reade= r.  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 mes= sages.
            &nb= sp;   
            &nb= sp;   
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

 


------ End of Forwarded Message
 --B_3178692742_3585648-- --B_3178692742_3596938 Content-type: application/octet-stream; name="ATT647424.TXT" Content-disposition: attachment; filename="ATT647424.TXT" Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWls LXNlcnZlciI7DQlzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0NQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTktMjExNTMxMzcuSS1EQGlldGYub3JnPg0N RU5DT0RJTkcgbWltZQ1GSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYW91bi12Nm9wcy1u YXRwdC1kZXByZWNhdGUtMDAudHh0DQ== --B_3178692742_3596938 Content-type: application/octet-stream; name="ATT647425.txt" Content-disposition: attachment; filename="ATT647425.txt" Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdA1JLUQtQW5ub3VuY2VAaWV0Zi5vcmcNaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQ== --B_3178692742_3596938-- From owner-v6ops@ops.ietf.org Wed Sep 22 04:37:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13647 for ; Wed, 22 Sep 2004 04:37:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CA2ch-0007Ut-Tj for v6ops-data@psg.com; Wed, 22 Sep 2004 08:37:11 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CA2c8-0007ND-BS for v6ops@ops.ietf.org; Wed, 22 Sep 2004 08:36:36 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8M8aZWR029202 for ; Wed, 22 Sep 2004 10:36:35 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Sep 2004 10:36:34 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TC4W5VFN; Wed, 22 Sep 2004 10:36:32 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Sep 2004 10:36:23 +0200 Message-ID: X-Sybari-Trust: b2c67148 47b3073a 3756a41f 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: V6OPS WG , "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Wed, 22 Sep 2004 10:36:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Sep 2004 08:36:34.0902 (UTC) FILETIME=[44D07760:01C4A07F] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Thanks. > > I'm not sure if there was a conclusion/resolution to this thread. > I am still looking for one... > As for my personal take -- hopefully I've understood the arguments > properly.. > > If you receive IPv4 ICMP error messages relating to an IPv6-in-IPv4 > tunnel, one should probably do something if it's possible, because > that will be an indication that IPv6 link layer has failed (and that > particular error can be propagated the same way as any other IPv6 link > failure, or by direct ICMP message conversion). > > What and whether the implementations must treat IPv4 ICMP error > messages somehow depends on the mechanism in question. > draft-ietf-v6ops-mech-v2-06.txt does not mandate it for static MTU > discovery, but it's obviously required for dynamic MTU discovery. > 6to4 spec (section 7) doesn't require it either, but seems to imply > that it can be done. > > So, as to the issue whether tunnel servers need to be able to send > back ICMPv6 error messages if the implementation thinks that the link > has failed, I'd say "yes, it probably should" because shouldn't all > IPv6 nodes be supposed to be able to do something like that. The > issue then is what constitutes good indication for "link failure" > (e.g., in this case, IPv4 tunneling failing). Specifying what that > must or should include is probably mechanism-dependent. > The tunnel servers are in many respects replacing IPv6 access routers, for which we have explicit requirements in this respect, i.e., SHOULD perform IPv6 NUD. If I understand you correctly you seem to be saying that not only is it up for the individual tunnel mechanism to decide how to perform determination of link-failure (with that, I agree completely) - but also (?) that it is up to the individual mechanism to determine what constitutes indication of link failure, and thus consequently, which kind of link failures that it will seek to monitor and report - !! I may not disagree with the latter, but if this is the route that we want to take, I would like it us to do it with our "eyes wide open" so to speak - saying clearly that in the areas of IPv6 black hole detection, tunnel servers may not provide a service comparatively with the native IPv6 one. BR, Karen > On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > > An issue of general character has been brought up in > connection with the zero-conf work. > > The issue is the following: > > > > MUST Ipv6-in-Ipv4 tunnel servers, as routers, support > NUD-like mechanisms that enables > > them to send ICMP destination unreachable messages back to origin ? > > > > The initial feedback received in this respect is that - > "yes, they MUST". > > > > As some RFCs previously has been silent about this, e.g. > 6to4 - RFC 3056, > > and the working group currently is standardising a > mechanism which also seems > > to be silent about this (Teredo) I would very much like to > hear if the above is the > > general sentiment of the work group. > > > > I should be stressed that adding this to the goals of the > zero-conf requirements > > document isn't believed to severely limit the solution > space - but it requires > > implementation of a mechanism which is know to scale very badly and > > which in addition is susceptible to the DoS attack > described in Section 4.3.2 of RFC 3756. > > > > BR, Karen > > > > > > > > > > > On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > > > > Normally last hops routers performs NUD so that they > can send ICMPs > > > > back to origin to notify of black holes/unreachability. > Personally > > > > I am not sure that this is a MUST requirement on the > Tunnel Servers. > > > > I have actually thought that we could avoid this, > especially since > > > > we have no explicit goals as to the nodes being registered as > > > > reachable in the DNS using the Ipv6 address - wherefore > we are first > > > > and foremost looking to support the situation where > communication is > > > > initiated by the tunnel clients and not from the outside. > > > > > > This seems short-sighted to me, because the actual > *advantage* of IPv6 > > > is realized only when *incoming* connectivity is enabled > (if it was > > > just about outbound connectivity, v4 would work as well). > > If this > > > would imply that the communication between two nodes > inside the 3GPP > > > network or communication originating from IPv6 internet > and coming to > > > a 3GPP node could just silently fail.. this would seem to be very > > > undesirable. > > > > Note this is not about the connectivity silently failing, it > > is about the node no longer being there/no longer being active. > > > > But what you're saying is that the destination unreachable > ICMPs are a MUST > > to support at a Ipv6-in-Ipv4 Tunnel Server ? > > > > - BTW, with the risk of bluring the difference in between > > solution space and requirement space - I suppose this in > particular applies > > to the v6ops accepted "tunnel server" mechanisms, 6to4 and > Teredo border routers ? > > > > > > > > -- > > > Pekka Savola "You each name yourselves > king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A > Clash of Kings > > > > > > > > > > -- > 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 Thu Sep 23 05:42:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26561 for ; Thu, 23 Sep 2004 05:42:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAQ4G-000Kdg-LH for v6ops-data@psg.com; Thu, 23 Sep 2004 09:39:12 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAQ45-000Kcl-Ej for v6ops@ops.ietf.org; Thu, 23 Sep 2004 09:39:01 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i8N9d0Li112304 for ; Thu, 23 Sep 2004 09:39:00 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i8N9cxU3211578 for ; Thu, 23 Sep 2004 11:38:59 +0200 Received: from zurich.ibm.com (sig-9-146-231-73.de.ibm.com [9.146.231.73]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA35854 for ; Thu, 23 Sep 2004 11:38:59 +0200 Message-ID: <415299B2.3070907@zurich.ibm.com> Date: Thu, 23 Sep 2004 11:38:58 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt References: <200409211938.PAA14143@ietf.org> In-Reply-To: <200409211938.PAA14143@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's not often I get to say "I told you so", but I told you so in RFC 1671, as far as the PT part of NAT-PT is concerned :-) I do agree with this draft and I think it pretty much covers the arguments, so I only have a couple of minor comments: > 1. Introduction ... > Some additional issues can be inferred from corresponding issues > known to exist in 'traditional' IPv4 NATs. The following documents > are relevant: > o Protocol Complications with the IP Network Address Translator > [RFC3027] > o IP Network Address Translator (NAT) Terminology and Considerations > [RFC2663] As well as RFC 2663 and 3027, I think you should refer to RFC 2993. I doubt if it brings in any new points, but that might be worth checking. > 8. Conclusion ... > Although some of issues identified with NAT-PT appear to have > solutions, many of the solutions required significant alterations to > the existing specification and would be likely to increase > operational complexity. Even if these solutions were applied, we > have shown that NAT-PT still has significant irresolvable issues, has > limited applicability and that alternatives exist. Accordingly we > invite the IETF to deprecate its usage within the Internet, move > RFC2766 to historic status Aren't you inviting the IESG to take action? IMHO the text should be more conclusive, e.g. Accordingly, this document deprecates its usage within the Internet. The IESG is requested to move RFC2766 to historic status. > ... and recommend, instead, the alternatives > discussed above. I don't think that you discuss the alternatives in any way to justify this final clause. So either you have to add a lot of words and citations, or change the final clause to Users are recommended to apply alternative techniques for coexistence. Regards Brian From owner-v6ops@ops.ietf.org Thu Sep 23 09:58:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14076 for ; Thu, 23 Sep 2004 09:58:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAU4L-0009p1-4x for v6ops-data@psg.com; Thu, 23 Sep 2004 13:55:33 +0000 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAU45-0009jP-3b for v6ops@ops.ietf.org; Thu, 23 Sep 2004 13:55:22 +0000 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i8NDtEb00271 for ; Thu, 23 Sep 2004 15:55:14 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Sep 2004 15:55:13 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D45800B@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'v6ops@ops.ietf.org'" Subject: IPv6 Fragment Overlap not Forbidden Date: Thu, 23 Sep 2004 15:55:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4A174.DBF3DA6A" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4A174.DBF3DA6A Content-Type: text/plain While writing the recent draft on NAT-PT deprecation, I had occasion to review RFC1838 and RFC3128 which relate to security threats with fragmented IPv4 packets. One of the problems was that the IPv4 specification allowed for fragments to overlap. It appears that the general assumption is that IPv6 stacks would not allow fragments to overlap but looking at RFC2460 the reconstruction algorithm specification does not forbid overlaps. If RFC2460 gets revved this point should be included. Regards, Elwyn ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. a ============================================================================ ====== ------_=_NextPart_001_01C4A174.DBF3DA6A Content-Type: text/html Content-Transfer-Encoding: quoted-printable IPv6 Fragment Overlap not Forbidden

While writing the recent draft on NAT-PT deprecation, = I had occasion to review RFC1838 and RFC3128 which relate to security = threats with fragmented IPv4 packets.  One of the problems was = that the IPv4 specification allowed for fragments to overlap.  It = appears that the general assumption is that IPv6 stacks would not allow = fragments to overlap but looking at RFC2460 the reconstruction = algorithm specification does not forbid overlaps. If RFC2460 gets = revved this point should be included.

Regards,
Elwyn

---------------------------------------------------------------= -------------------

Elwyn B Davies

        Routing = and Addressing Strategy Prime & IPv6 Core Team Leader
        CTO = Office, Portfolio Integration       =         Solutions Ready =        

        Nortel = Networks plc     =         =         Email: = elwynd@nortelnetworks.com
        Harlow = Laboratories     =         =         = ESN           &nb= sp;         6-742-5498
        London = Road, Harlow,    =         =         Direct = Line             = +44-1279-405498
        Essex, = CM17 9NA, UK     =         =         = Fax           &nb= sp;         +44-1279-402047
        = Registered Office:      =         =         Maidenhead Office Park, = Westacott Way,
        Company = No. 3937799     =         =         Maidenhead, Berkshire, SSL6 = 3QH
---------------------------------------------------------------= -------------
This message may contain information proprietary to = Nortel Networks plc so any
unauthorised disclosure, copying or distribution of = its contents is strictly prohibited.
---------------------------------------------------------------= -------------
"The Folly is mostly mine"
and the opinions are mine and not those of my = employer. a
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


------_=_NextPart_001_01C4A174.DBF3DA6A-- From owner-v6ops@ops.ietf.org Thu Sep 23 13:33:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03432 for ; Thu, 23 Sep 2004 13:33:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAXR8-000GB5-LJ for v6ops-data@psg.com; Thu, 23 Sep 2004 17:31:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAXQx-000GA0-0F for v6ops@ops.ietf.org; Thu, 23 Sep 2004 17:31:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8NHV5c16117 for ; Thu, 23 Sep 2004 20:31:05 +0300 Date: Thu, 23 Sep 2004 20:31:04 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI. ---------- Forwarded message ---------- Date: Thu, 23 Sep 2004 11:48:50 -0400 From: The IESG Reply-To: iesg@ietf.org To: IETF-Announce Subject: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Teredo: Tunneling IPv6 over UDP through NATs' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-10-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-02.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-v6ops@ops.ietf.org Thu Sep 23 15:04:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11345 for ; Thu, 23 Sep 2004 15:04:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAYqn-0003RU-Bt for v6ops-data@psg.com; Thu, 23 Sep 2004 19:01:53 +0000 Received: from [207.69.200.246] (helo=smtp10.atl.mindspring.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAYqM-0003O4-O0 for v6ops@ops.ietf.org; Thu, 23 Sep 2004 19:01:26 +0000 Received: from [192.168.167.39] (helo=wamui01.slb.atl.earthlink.net) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1CAYqL-0001GU-00 for v6ops@ops.ietf.org; Thu, 23 Sep 2004 15:01:25 -0400 Message-ID: <21663207.1095966085332.JavaMail.root@wamui01.slb.atl.earthlink.net> Date: Thu, 23 Sep 2004 12:01:25 -0700 (GMT-07:00) From: kck@netcom.com Reply-To: kck@netcom.com To: IPv6 Operations Subject: Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----Original Message----- >I do agree with this draft and I think it pretty much covers >the arguments, so I only have a couple of minor comments: I agree that this was well written and informative. 2 points and 2 grammar nits. 1. section 2.4 Loss of Information through Incompatible Semantics Isn't this true even if NAT is not used when going between IPv4 and IPv6 to some degree? While I think its a good point I think a statement to this affect is a warranted. 2. UDP checksums == 0. I do not know how prevalent this behaviour is today, but if applications trust the network enough to not checksum, then they deserve the added delay. In fact, if a NAT dropped such messages I would not lose any sleep, due to the numerous problems this can create on a NAT box. But I think the text should state that sending datagrams into the Internet unchecksummed is not advisable and use that as a solution. In other words, I think the document should lessen the concern regarding this issue, since it raises so many other concerns that are really germane to point of the document. 2 grammar nitpicks, both on page 15: "the the" and "ifit" --rich From owner-v6ops@ops.ietf.org Thu Sep 23 17:10:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23317 for ; Thu, 23 Sep 2004 17:10:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAaoZ-000LPy-5I for v6ops-data@psg.com; Thu, 23 Sep 2004 21:07:43 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CAaoO-000LNt-6w for v6ops@ops.ietf.org; Thu, 23 Sep 2004 21:07:32 +0000 Received: (qmail 29221 invoked by uid 417); 23 Sep 2004 20:08:39 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 23 Sep 2004 20:08:39 -0000 Received: from XPNERICK ([132.70.218.240]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 23 Sep 2004 14:08:38 -0600 Message-ID: <002401c4a1a8$fbe17150$0401a8c0@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: Subject: Re: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard (fwd) Date: Thu, 23 Sep 2004 22:07:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit General comment: As IPv6 does not support NAT in any native form I would like to see the term NAT replaced with IPv4 NAT through out the docuement, and a comment at the start to the effect that there is no such thing as IPv6 NAT. Speciffic comments: Section 3.1 reads: The type of mappings is analyzed in [RFC3489], which distinguishes between "Cone NAT", "restricted cone NAT", "port restricted cone NAT" and "symmetric NAT". The Teredo solution ensures connectivity for clients located behind cone NATs, retricted cone NATs or port- restricted cone NATs. these three types NATs. Some how that last three types of NATs slipped in past editing. 3.2.4 Automatic sunset Some how this whole section scares me as it seems to imply that there is a way to turn an IPv4 NAT into an IPv6 Router while maintaining the NAT like functionality. As stated above, NAT is not part of IPv6 (NAP is but is not mentioned in this document). Final comment: I am also unclear why it is assumed that UDP is the prefered protocol. UDP has no retransmits, so lost packets will stay lost while TCP has retransmit based on acknowledgements. WHy force this on UDP? Eric ----- Original Message ----- From: "Pekka Savola" To: Sent: 23 September, 2004 7:31 PM Subject: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard (fwd) > FYI. > > ---------- Forwarded message ---------- > Date: Thu, 23 Sep 2004 11:48:50 -0400 > From: The IESG > Reply-To: iesg@ietf.org > To: IETF-Announce > Subject: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to > Proposed Standard > > The IESG has received a request from an individual submitter to consider the > following document: > > - 'Teredo: Tunneling IPv6 over UDP through NATs' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-10-20. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-02.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > From owner-v6ops@ops.ietf.org Thu Sep 23 17:58:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27200 for ; Thu, 23 Sep 2004 17:58:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAbZp-0001yf-Ha for v6ops-data@psg.com; Thu, 23 Sep 2004 21:56:33 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAbZd-0001xf-K2 for v6ops@ops.ietf.org; Thu, 23 Sep 2004 21:56:21 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 23 Sep 2004 15:01:47 -0700 X-BrightmailFiltered: true Received: from sasad-w2k01.cisco.com (sjc-vpn5-243.cisco.com [10.21.88.243]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8NLuFbt011367; Thu, 23 Sep 2004 14:56:16 -0700 (PDT) Message-Id: <4.3.2.7.2.20040923134651.026cfe20@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Sep 2004 14:56:15 -0700 To: Pekka Savola From: Salman Asadullah Subject: Re: Draft on ISP broad-band deployment scenarios Cc: Adeel Ahmed , Ciprian Popoviciu , , Patrick Grossetete In-Reply-To: References: <4.3.2.7.2.20040910170906.0173e1e8@cactus> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_104478922==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_104478922==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello Pekka, Please see our response below between &&&. At 09:58 AM 9/22/2004 +0300, Pekka Savola wrote: >Hi, > >Sorry for not getting back to this earlier :-(.. inline.. > >On Fri, 10 Sep 2004, Adeel Ahmed wrote: > > Please see my responses inline with +++++++++++++++: > > > > At 02:43 PM 9/7/2004 +0300, Pekka Savola wrote: > > >Sorry for the delay in responding.. inline... > > > > > >(I've removed some comments which we seemed to agree or be clear > > >about.) > > > > > >On Wed, 1 Sep 2004, Ciprian Popoviciu wrote: > > > > >On Thu, 19 Aug 2004, Pekka Savola wrote: > > > > > > Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco > did a > > > > > > lot of work in a very short time and produced a really extensive > > > > > > scenarios document discussing the IPv6 deployment scenarios for > > > > > > broadband (DSL, cable, etc.). > > > > > > > > > >A couple of general observations: > > > > > > > > > > 0) is the document aiming to only describe the scenarios, or is the > > > > >goal to also provide analysis where potential gaps have been > > > > >identified, and where e.g., a tunneling mechanism would be needed? If > > > > >the latter, it probably needs to be expanded a bit. > > > > > > > > @@@ > > > > Pekka, to put this document in perspective, here are some elements > of our > > > > original intent: > > > > - focus on production type deployments. We did not intend to discuss > > > tunneling > > > > unless it is the only alternative currently available due to > > > limitations of > > > > a given access > > > > technology (cable). > > > > > >OK, though I'm not sure how certain types of tunneling solutions could > > >not be considered "production" (or sufficiently near that) to be > > >useful on a larger scale. The justification for that is that there > > >may be lots of equipment that is not IPv6-capable, and having to wait > > >for it to be replaced to be able to offer (or get) IPv6 connectivity > > >may be a big assumption for deployment. > > > > > > +++++++++++++++ > > Our goal in this draft is to get SPs to move towards deployment of > > native IPv6. So leading to such deployments tunneling would be a > > stepping stone for the SPs. However, considering that there are > > native deployments today, we wanted to focus more on them rather > > then on the transitional phase in which it might be rather difficult > > for an SP to generate revenue from a tunnel based service till they > > move towards native IPv6 deployments. > >There are native deployments today, but AFAIK they have been >relatively small scale (thousands of users). > >The crux is whether the ISP wants to (try to) offer service to *all* >of its customers, requiring no hardware upgrades or purchases, with no >assumptions about what the user has deployed -- or just those which >are OK the assumptions, upgrades/purchases, etc. > >I'm concerned that if we focus too much on "native only", only >(relatively) few users will likely be able to get the service. > >It's true that it may be difficult for an ISP to generate revenue out >of e.g., tunneling based service, offered to anyone, but if some ISP's >are still interested in this kind of approach, would it be worth >considering? &&& This is true but we have observed many of the BB ISPs are interested in deploying native IPv6, driven by new services such as VoD using Multicast and etc. Some of the examples for these BB ISPs, who are deploying IPv6 are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in France, XS4ALL in The Netherlands and etc. Our intent in this draft is to the make the worldwide BB ISP community aware of possible options available to deploy IPv6 natively today. We agree that for some ISPs the native IPv6 solution would not be feasible due to several reasons as you mentioned previously, with the information provided in our draft, some ISPs might realize that the extra investment for a native deployment might make sense for their long term goals. Besides, for some countries this might be a viable option, think of Japan, Korea and some other countries where the ISPs are getting tax cuts from the government, if they deploy IPv6. &&& > > > In the case of Cable (section 5) we had to talk about tunnels due to > > the current limitations in DOCSIS but all the other access > > technologies discussed in the draft are ready for native IPv6 > > deployment today. > > +++++++++++++++ > >The approach depends on the ISP's strategy. If it wants to offer >services to just those which have the right kind of set-up, no >interfering NAT boxes, their own wireless routers, or whatever, that's >fine. But I'm quite concerned about making such assumptions, because >in practice that implies that the deployment gets much more difficult >and demanding (also due to need for financial justifications) for the >users. > > > >The question I was asking was whether you intended to analyze the > > >applicability of different methods for getting IPv6 connectivity (in > > >case there would be multiple: for example, where you cite 6to4, there > > >could very likely be others as well, possibly even more suitable than > > >that), or just pick one (or none) and describe how that would work. > > >In other words, I was interested whether you were considering > > >"generic" deployment (with as few assumptions as reasonable, about, > > >e.g., equipment at the customer's premises), or "specific" deployment > > >(where you could or could not assume some things, like being able to > > >upgrade a certain box or having public IPv4 addresses). > > > > > >The document would certainly seem to be most useful if it was > > >sufficiently "generic", but a "specific" document is also better than > > >nothing ;-), provided that the assumptions are very clearly spelled > > >out. > > > > +++++++++++++++ > > We've actually tried to be specific in sections 6,7 & 8. We've used > > kind of a generic approach in section 5 due to the current state of > > cable networks and the limitations in DOCSIS. We will try to spell > > out some of the assumptions more clearly in our next revision of the > > draft. > > +++++++++++++++ > >OK. Please also state clearly the caveats of "native only, if >technologically possible" approach (discussed above, for example). &&& Sure. Will do. &&& > > > > > 2) the document seems to make some assumptions e.g., when it > > > specifies to > > > > >use 6to4 e.g., for cable. Are all of the networks using public v4 > > > > >addresses? What if the customer has deployed a NAT box so that the > public > > > > >address is consumed by that box? Further, I'm not sure whether the > > > > >situation where the customer has deployed some equipment has been > > > considered > > > > >throughout the document. > > > > > > > > @@@ > > > > Again, it is a case very specific to the current state of Cable > > > > access. > > > > > >Do you mean that cable operators are widely offering a public IP > > >address per customer? However, I'd venture to guess there are a > > >significant number of operators which only give private addresses to > > >begin with. > > > > +++++++++++++++ > > Actually that is a common practice with most Cable > > Operators. We've worked with major Cable providers in the America, > > EMEA and APAC regions and they all offer public IP addresses to > > their customers. > > +++++++++++++++ > >OK, please make this assumption and justification explicit in the >document. &&& Sure. Will do. &&& > > > > Nevertheless we could probably offer more detail for this > > > > case. For example, one solution would be to have the box that is > > > > doing the NAT for the user also terminate the tunnel. > > > > > > > > This is another point that we need to clarify however, the Gateway > > > > Router (GWR) can be SP owned but also it can be customer owned and > > > > in that case it would reflect a customer deployed equipment like a > > > > box that does NAT for v4. > > > > @@@ > > > > > >Exactly, this cuts both ways: one approach could be to assume that the > > >NAT box (which may be beyond the control of the SP) is upgraded -- > > >this could take quite a long time to achieve. Another approach could > > >be to provide mechanisms which work irrespective of NATs -- there are > > >already a plenty of those, for example Teredo, and some others > > >probably to come (think of "configured tunneling over UDP with > > >keepalives"), in one form or the other. > > > > > >I think what you were assuming that you only need to care about the > > >case of upgrading the NAT box. That may be acceptable with certain > > >assumptions about the deployment (if that's the case, they must be > > >very clearly spelled out), but it may not be sufficient in more > > >general -- so if you agree that one would want to provide v6 access > > >also when there are NATs or other obstacles in the way, one such > > >approach is to specify v6 connectivity mechanissm which work through a > > >NAT. > > > > +++++++++++++++ > > That's a good point, we will make a note of that in section 5 where we > > discuss initiating a tunnel from > > the host. Since our goal is to provide IPv6 access natively this should > not > > be an issue for other technologies. > > +++++++++++++++ > >OK. > > > > > @@@ > > > > These are deployment issues that we could elaborate a bit more on. The > > > > provider usually > > > > is not responsible for the additional equipment added by the > customer and > > > > under the > > > > constraints of a service deployment that is limited by the current > > > state of > > > > DOCSIS it is likely that > > > > the provider will have to provide a new device to the subscriber. > We will > > > > add a note on this > > > > topic. > > > > @@@ > > > > > >This is one approach, as noted at the start of the message; another is > > >providing tunneling support. Both could be feasible, depending on > > >deployment, but the latter is more generic at least. > > > > +++++++++++++++ > > Right, so cable operators currently do provide a GWR which is managed by > > them. In order > > to deploy IPv6 the operator can upgrade or replace this GWR with a v6 > > capable device. > > +++++++++++++++ > >Right. But my practical concern is that if it costs the ISP XXX XXX $ >to replace the GWR's with ipv6-supporting versions, but XXXX $ (XXX >XXX >> XXXX) to provide tunneling support, I'd guess most ISPs would >be interested in going for tunneling first, and just looking at >replacing GWR's based on their natural EOL schedule. &&& You are correct, the first step in some cases will be tunneling (for example cable). But in other cases BB ISPs are taking the next step and inclined more towards the native deployments Also the extra cost might be justified by the: - Services provided and charges ($$ earned) over IPv6 like VoD, video streaming, IPT and etc. - Tax cuts received by the governments for IPv6 deployments - and etc. &&& > > >OK -- I'm just having trouble visualizing any ISP doing so, because > > >that might directly jeopardize their IGP to the customers.. and I'd be > > >interested in hearing why they would be doing something like this (is > > >this some kind of backup routing plan for some SOHO customers or the > > >like or what). > > > > +++++++++++++++ > > This is currently a normal practice for Cable Operator's business > customers. > > There are only a handful of these customer routes which are summarized and > > redistributed into the Cable Operator's IGP. This is not really meant for > > residential > > customers which account for majority of the customer base. > > +++++++++++++++ > >But what I don't understand is why the business customers would 1) >need dynamic routing in the first place (what is the actual reason for >using a routing protocol?), &&& The cable business customers in todays world get a /27 or something similar. The issue is how does the CMTS keep track of which business customer owns that particular /27 and how does it get advertised to the rest of the world. One way to do this is to use static routing but the problem is that if the cable modem goes down, the CMTS will end up black holing that traffic and vise versa, thus requiring an IGP. There are several reasons of using RIPv2, out of which a simple one is that there are hardly any CM/GWR which support OSPF. Today's cable deployments uses this, so we had to discuss it in the draft to make it close to reality. The BB ISP will use RIPng as they were using RIPv2. We felt this explanation is out of the scope of this document so we did not include. &&& >and 2) would want to use something as >"unreliable" (with some definition of unreliable) as Cable, instead of >DSL, Serial, Ethernet. &&& Sure, there are pros and cons with every technology. If you ask me personally, I prefer Cable over DSL :-) &&& > > > > > >6.2.1 POINT-TO-POINT MODEL > > > > > > > > > > > > > > >==> this model has the built-in assumption that ATM is used as > > > > >point-to-point. Is this strictly necessary, or could you just use any > > > other > > > > >media as well? > > > > > > > > @@@ > > > > Could you please clarify this comment? > > > > @@@ > > > > > >I meant that wouldn't it be possible to use e.g., Ethernet (instead of > > >ATM) as the point-to-point uplink? I haven't seen this myself, but > > >I've heard reports of such deployments.. > > > > +++++++++++++++ > > We've discussed this in the FTTH section 7.2.1. So we did not really > assume > > that only ATM will be used as a point-to-point uplink. > > +++++++++++++++ > >But couldn't you provide ADSL (instead of FTTH or Ethernet to the >home) using Ethernet or something like HomePNA on the uplink instead >of ATM? > >I don't know enough of the deployments to be able to say whether "ADSL >with Ethernet-like uplink" and "FTTH" are synonymous, but if I had to >venture a guess, I'd say there's probably some difference there. &&& Sure. We'll investigate some of the differences. &&& > > > > @@@ > > > > Why would you see it as a bad practice having the router acquire via > > > stateless > > > > autoconfig an address for the uplink to the provider? We should > probably > > > > discuss > > > > all options for completeness purposes. > > > > @@@ > > > > > >Well, if you have a router, I'd generally expect it to act as a router > > >on all of its interfaces. There has been some debate of this mixed > > >"host/router" behaviour on IPv6 WG list before, but I think the > > >conclusion has been that mixed host/router is acceptable by the specs > > >at least. I'd however personally rather see that the routers in these > > >situations would have other means to configure an address (if they > > >need one). > > > > +++++++++++++++ > > We've seen customer interest in using this approach for IPv6 therefore we > > discuss it in the draft. > > Similar approach is also available in IPv4. > > +++++++++++++++ > >Please state explicitly that this is takes a mixed host/router >approach to ND. &&& Sure. Will do. &&& > > >These arguments should maybe go in the draft, but still keep in mind > > >that MLD/IGMP have not been meant to authenticate the users. > > > > > >I'd expect that the same features can be obtained with encrypted data. > > >You would get the key which would be valid only for some time from a > > >web server, and that key would be only valid for a certain stream. > > >That way you could get the keys etc. only only those parts of the > > >transmission you'd want. There are possibly other approaches. MSEC > > >(http://www.ietf.org/html.charters/msec-charter.html) WG has been > > >looking at this problem. > > > > +++++++++++++++ > > We do realize that there are multiple ways of doing this but we went with > > MLD authentication approach because we have seen requirements for this > > from customers and it's a rather simple approach. > > > > But we will try to add more explanation in the next revision of the draft. > > +++++++++++++++ > >Thanks. Justification and listing the caveats is good. &&& And thanks for your time and continuos valuable feedback :-) &&& Regards, Salman Asadullah Technical Leader Cisco Systems, Inc. >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --=====================_104478922==_.ALT Content-Type: text/html; charset="us-ascii" Hello Pekka,

Please see our response below between &&&.

At 09:58 AM 9/22/2004 +0300, Pekka Savola wrote:
Hi,

Sorry for not getting back to this earlier :-(.. inline..

On Fri, 10 Sep 2004, Adeel Ahmed wrote:
> Please see my responses inline with +++++++++++++++:
>
> At 02:43 PM 9/7/2004 +0300, Pekka Savola wrote:
> >Sorry for the delay in responding.. inline...
> >
> >(I've removed some comments which we seemed to agree or be clear
> >about.)
> >
> >On Wed, 1 Sep 2004, Ciprian Popoviciu wrote:
> > > >On Thu, 19 Aug 2004, Pekka Savola wrote:
> > > > > Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a
> > > > > lot of work in a very short time and produced a really extensive
> > > > > scenarios document discussing the IPv6 deployment scenarios for
> > > > > broadband (DSL, cable, etc.).
> > > >
> > > >A couple of general observations:
> > > >
> > > > 0) is the document aiming to only describe the scenarios, or is the
> > > >goal to also provide analysis where potential gaps have been
> > > >identified, and where e.g., a tunneling mechanism would be needed? If
> > > >the latter, it probably needs to be expanded a bit.
> > >
> > > @@@
> > > Pekka, to put this document in perspective, here are some elements of our
> > > original intent:
> > > - focus on production type deployments. We did not intend to discuss
> > tunneling
> > > unless it is the only alternative currently available due to
> > limitations of
> > > a given access
> > > technology (cable).
> >
> >OK, though I'm not sure how certain types of tunneling solutions could
> >not be considered "production" (or sufficiently near that) to be
> >useful on a larger scale. The justification for that is that there
> >may be lots of equipment that is not IPv6-capable, and having to wait
> >for it to be replaced to be able to offer (or get) IPv6 connectivity
> >may be a big assumption for deployment.
>
>
> +++++++++++++++
> Our goal in this draft is to get SPs to move towards deployment of
> native IPv6. So leading to such deployments tunneling would be a
> stepping stone for the SPs. However, considering that there are
> native deployments today, we wanted to focus more on them rather
> then on the transitional phase in which it might be rather difficult
> for an SP to generate revenue from a tunnel based service till they
> move towards native IPv6 deployments.

There are native deployments today, but AFAIK they have been
relatively small scale (thousands of users).

The crux is whether the ISP wants to (try to) offer service to *all*
of its customers, requiring no hardware upgrades or purchases, with no
assumptions about what the user has deployed -- or just those which
are OK the assumptions, upgrades/purchases, etc.

I'm concerned that if we focus too much on "native only", only
(relatively) few users will likely be able to get the service.

It's true that it may be difficult for an ISP to generate revenue out
of e.g., tunneling based service, offered to anyone, but if some ISP's
are still interested in this kind of approach, would it be worth
considering?

&&&
This is true but we have observed many of the BB ISPs are interested in deploying native IPv6, driven by new services such as VoD using Multicast and etc.  Some of the examples for these BB ISPs, who are deploying IPv6 are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in France, XS4ALL in The Netherlands and etc.

Our intent in this draft is to the make the worldwide BB ISP community aware of possible options available to deploy IPv6 natively today.

We agree that for some ISPs the native IPv6 solution would not be feasible due to several reasons as you mentioned previously, with the information provided in our draft, some ISPs might realize that the extra investment for a native deployment might make sense for their long term goals.  Besides, for some countries this might be a viable option, think of Japan, Korea and some other countries where the ISPs are getting tax cuts from the government, if they deploy IPv6.
&&&

 
> In the case of Cable (section 5) we had to talk about tunnels due to
> the current limitations in DOCSIS but all the other access
> technologies discussed in the draft are ready for native IPv6
> deployment today.
> +++++++++++++++

The approach depends on the ISP's strategy. If it wants to offer
services to just those which have the right kind of set-up, no
interfering NAT boxes, their own wireless routers, or whatever, that's
fine. But I'm quite concerned about making such assumptions, because
in practice that implies that the deployment gets much more difficult
and demanding (also due to need for financial justifications) for the
users.

> >The question I was asking was whether you intended to analyze the
> >applicability of different methods for getting IPv6 connectivity (in
> >case there would be multiple: for example, where you cite 6to4, there
> >could very likely be others as well, possibly even more suitable than
> >that), or just pick one (or none) and describe how that would work.
> >In other words, I was interested whether you were considering
> >"generic" deployment (with as few assumptions as reasonable, about,
> >e.g., equipment at the customer's premises), or "specific" deployment
> >(where you could or could not assume some things, like being able to
> >upgrade a certain box or having public IPv4 addresses).
> >
> >The document would certainly seem to be most useful if it was
> >sufficiently "generic", but a "specific" document is also better than
> >nothing ;-), provided that the assumptions are very clearly spelled
> >out.
>
> +++++++++++++++
> We've actually tried to be specific in sections 6,7 & 8. We've used
> kind of a generic approach in section 5 due to the current state of
> cable networks and the limitations in DOCSIS. We will try to spell
> out some of the assumptions more clearly in our next revision of the
> draft.
> +++++++++++++++

OK. Please also state clearly the caveats of "native only, if
technologically possible" approach (discussed above, for example).

&&&
Sure. Will do.
&&&


> > > > 2) the document seems to make some assumptions e.g., when it
> > specifies to
> > > >use 6to4 e.g., for cable. Are all of the networks using public v4
> > > >addresses? What if the customer has deployed a NAT box so that the public
> > > >address is consumed by that box? Further, I'm not sure whether the
> > > >situation where the customer has deployed some equipment has been
> > considered
> > > >throughout the document.
> > >
> > > @@@
> > > Again, it is a case very specific to the current state of Cable
> > > access.
> >
> >Do you mean that cable operators are widely offering a public IP
> >address per customer? However, I'd venture to guess there are a
> >significant number of operators which only give private addresses to
> >begin with.
>
> +++++++++++++++
> Actually that is a common practice with most Cable
> Operators. We've worked with major Cable providers in the America,
> EMEA and APAC regions and they all offer public IP addresses to
> their customers.
> +++++++++++++++

OK, please make this assumption and justification explicit in the
document.

&&&
Sure. Will do.
&&&


> > > Nevertheless we could probably offer more detail for this
> > > case. For example, one solution would be to have the box that is
> > > doing the NAT for the user also terminate the tunnel.
> > >
> > > This is another point that we need to clarify however, the Gateway
> > > Router (GWR) can be SP owned but also it can be customer owned and
> > > in that case it would reflect a customer deployed equipment like a
> > > box that does NAT for v4.
> > > @@@
> >
> >Exactly, this cuts both ways: one approach could be to assume that the
> >NAT box (which may be beyond the control of the SP) is upgraded --
> >this could take quite a long time to achieve. Another approach could
> >be to provide mechanisms which work irrespective of NATs -- there are
> >already a plenty of those, for example Teredo, and some others
> >probably to come (think of "configured tunneling over UDP with
> >keepalives"), in one form or the other.
> >
> >I think what you were assuming that you only need to care about the
> >case of upgrading the NAT box. That may be acceptable with certain
> >assumptions about the deployment (if that's the case, they must be
> >very clearly spelled out), but it may not be sufficient in more
> >general -- so if you agree that one would want to provide v6 access
> >also when there are NATs or other obstacles in the way, one such
> >approach is to specify v6 connectivity mechanissm which work through a
> >NAT.
>
> +++++++++++++++
> That's a good point, we will make a note of that in section 5 where we
> discuss initiating a tunnel from
> the host. Since our goal is to provide IPv6 access natively this should not
> be an issue for other technologies.
> +++++++++++++++

OK.
 
> > > @@@
> > > These are deployment issues that we could elaborate a bit more on. The
> > > provider usually
> > > is not responsible for the additional equipment added by the customer and
> > > under the
> > > constraints of a service deployment that is limited by the current
> > state of
> > > DOCSIS it is likely that
> > > the provider will have to provide a new device to the subscriber. We will
> > > add a note on this
> > > topic.
> > > @@@
> >
> >This is one approach, as noted at the start of the message; another is
> >providing tunneling support. Both could be feasible, depending on
> >deployment, but the latter is more generic at least.
>
> +++++++++++++++
> Right, so cable operators currently do provide a GWR which is managed by
> them. In order
> to deploy IPv6 the operator can upgrade or replace this GWR with a v6
> capable device.
> +++++++++++++++

Right. But my practical concern is that if it costs the ISP XXX XXX $
to replace the GWR's with ipv6-supporting versions, but XXXX $ (XXX
XXX >> XXXX) to provide tunneling support, I'd guess most ISPs would
be interested in going for tunneling first, and just looking at
replacing GWR's based on their natural EOL schedule.

&&&
You are correct, the first step in some cases will be tunneling (for example cable).

But in other cases BB ISPs are taking the next step and inclined more towards the native deployments

Also the extra cost might be justified by the:

- Services provided and charges ($$ earned) over IPv6 like VoD, video streaming, IPT and etc.
- Tax cuts received by the governments for IPv6 deployments
- and etc.
&&&

> >OK -- I'm just having trouble visualizing any ISP doing so, because
> >that might directly jeopardize their IGP to the customers.. and I'd be
> >interested in hearing why they would be doing something like this (is
> >this some kind of backup routing plan for some SOHO customers or the
> >like or what).
>
> +++++++++++++++
> This is currently a normal practice for Cable Operator's business customers.
> There are only a handful of these customer routes which are summarized and
> redistributed into the Cable Operator's IGP. This is not really meant for
> residential
> customers which account for majority of the customer base.
> +++++++++++++++

But what I don't understand is why the business customers would 1)
need dynamic routing in the first place (what is the actual reason for
using a routing protocol?),

&&&
The cable business customers in todays world get a /27 or something similar.  The issue is how does the CMTS keep track of which business customer owns that particular /27 and how does it get advertised to the rest of the world.  One way to do this is to use static routing but the problem is that if the cable modem goes down, the CMTS will end up black holing that traffic and vise versa, thus requiring an IGP. There are several reasons of using RIPv2, out of which a simple one is that there are hardly any CM/GWR which support OSPF.

Today's cable deployments uses this, so we had to discuss it in the draft to make it close to reality.  The BB ISP will use RIPng as they were using RIPv2. We felt this explanation is out of the scope of this document so we did not include.
&&& 

and 2) would want to use something as
"unreliable" (with some definition of unreliable) as Cable, instead of
DSL, Serial, Ethernet.

&&&
Sure, there are pros and cons with every technology.  If you ask me personally, I prefer Cable over DSL :-)
&&&

 
> > > >6.2.1 POINT-TO-POINT MODEL
> > > >
> > > >
> > > >==> this model has the built-in assumption that ATM is used as
> > > >point-to-point. Is this strictly necessary, or could you just use any
> > other
> > > >media as well?
> > >
> > > @@@
> > > Could you please clarify this comment?
> > > @@@
> >
> >I meant that wouldn't it be possible to use e.g., Ethernet (instead of
> >ATM) as the point-to-point uplink? I haven't seen this myself, but
> >I've heard reports of such deployments..
>
> +++++++++++++++
> We've discussed this in the FTTH section 7.2.1. So we did not really assume
> that only ATM will be used as a point-to-point uplink.
> +++++++++++++++

But couldn't you provide ADSL (instead of FTTH or Ethernet to the
home) using Ethernet or something like HomePNA on the uplink instead
of ATM?

I don't know enough of the deployments to be able to say whether "ADSL
with Ethernet-like uplink" and "FTTH" are synonymous, but if I had to
venture a guess, I'd say there's probably some difference there.

&&&
Sure. We'll investigate some of the differences.
&&&


> > > @@@
> > > Why would you see it as a bad practice having the router acquire via
> > stateless
> > > autoconfig an address for the uplink to the provider? We should probably
> > > discuss
> > > all options for completeness purposes.
> > > @@@
> >
> >Well, if you have a router, I'd generally expect it to act as a router
> >on all of its interfaces. There has been some debate of this mixed
> >"host/router" behaviour on IPv6 WG list before, but I think the
> >conclusion has been that mixed host/router is acceptable by the specs
> >at least. I'd however personally rather see that the routers in these
> >situations would have other means to configure an address (if they
> >need one).
>
> +++++++++++++++
> We've seen customer interest in using this approach for IPv6 therefore we
> discuss it in the draft.
> Similar approach is also available in IPv4.
> +++++++++++++++

Please state explicitly that this is takes a mixed host/router
approach to ND.

&&&
Sure. Will do.
&&&


> >These arguments should maybe go in the draft, but still keep in mind
> >that MLD/IGMP have not been meant to authenticate the users.
> >
> >I'd expect that the same features can be obtained with encrypted data.
> >You would get the key which would be valid only for some time from a
> >web server, and that key would be only valid for a certain stream.
> >That way you could get the keys etc. only only those parts of the
> >transmission you'd want. There are possibly other approaches. MSEC
> >(http://www.ietf.org/html.charters/msec-charter.html) WG has been
> >looking at this problem.
>
> +++++++++++++++
> We do realize that there are multiple ways of doing this but we went with
> MLD authentication approach because we have seen requirements for this
> from customers and it's a rather simple approach.
>
> But we will try to add more explanation in the next revision of the draft.
> +++++++++++++++

Thanks. Justification and listing the caveats is good.

&&&
And thanks for your time and continuos valuable feedback :-)
&&&

Regards,
Salman Asadullah
Technical Leader
Cisco Systems, Inc.


--
Pekka Savola                "You each name yourselves king, yet the
Netcore Oy                   kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=====================_104478922==_.ALT-- From owner-v6ops@ops.ietf.org Fri Sep 24 02:24:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12547 for ; Fri, 24 Sep 2004 02:24:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAjTN-00067e-NC for v6ops-data@psg.com; Fri, 24 Sep 2004 06:22:25 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAjTC-00065c-Qq for v6ops@ops.ietf.org; Fri, 24 Sep 2004 06:22:15 +0000 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id E31C1800D; Fri, 24 Sep 2004 08:22:10 +0200 (CEST) Received: from purgatory.unfix.org ([127.0.0.1]) by localhost (purgatory [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 09647-45; Fri, 24 Sep 2004 08:22:06 +0200 (CEST) Received: from [9.4.68.125] (pat.zurich.ibm.com [195.176.20.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 26AA07FC5; Fri, 24 Sep 2004 08:22:06 +0200 (CEST) Subject: Re: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard (fwd) From: Jeroen Massar To: EricLKlein Cc: v6ops@ops.ietf.org In-Reply-To: <002401c4a1a8$fbe17150$0401a8c0@ttitelecom.com> References: <002401c4a1a8$fbe17150$0401a8c0@ttitelecom.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aB6NEcWHyN9k0zcEXHGS" Organization: Unfix Message-Id: <1096006918.13276.20.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 24 Sep 2004 08:21:58 +0200 X-Virus-Scanned: purgatory.unfix.org - http://unfix.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=-aB6NEcWHyN9k0zcEXHGS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-09-23 at 22:07, EricLKlein wrote: > General comment: > As IPv6 does not support NAT in any native form I would like to see the t= erm > NAT replaced with IPv4 NAT through out the docuement, and a comment at th= e > start to the effect that there is no such thing as IPv6 NAT. NAT is an IPv4 only thing, there must be no IPv6 NAT, better to not name it separately IMHO. > Final comment: > I am also unclear why it is assumed that UDP is the prefered protocol. UD= P > has no retransmits, so lost packets will stay lost while TCP has retransm= it > based on acknowledgements. WHy force this on UDP? Because the IP protocol running inside UDP will take care of the retransmits and if you are doing IPv6 over TCP you will need to reorder packets, keep connections open, state etc. Greets, Jeroen --=-aB6NEcWHyN9k0zcEXHGS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBU70GKaooUjM+fCMRAsLWAJ9k2GZ3EAeH5XVNl2ysLvhfl4/CnwCgt0ug 3OAoD1Ub8fGztbm0a6AG3E8= =MQPE -----END PGP SIGNATURE----- --=-aB6NEcWHyN9k0zcEXHGS-- From owner-v6ops@ops.ietf.org Fri Sep 24 02:31:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12879 for ; Fri, 24 Sep 2004 02:31:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAjbZ-0007Rb-B4 for v6ops-data@psg.com; Fri, 24 Sep 2004 06:30:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAjbO-0007Pu-Gv for v6ops@ops.ietf.org; Fri, 24 Sep 2004 06:30:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8O6UFg01326; Fri, 24 Sep 2004 09:30:17 +0300 Date: Fri, 24 Sep 2004 09:30:15 +0300 (EEST) From: Pekka Savola To: Jeroen Massar cc: EricLKlein , Subject: Re: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard (fwd) In-Reply-To: <1096006918.13276.20.camel@firenze.zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 24 Sep 2004, Jeroen Massar wrote: > > Final comment: > > I am also unclear why it is assumed that UDP is the prefered protocol. UDP > > has no retransmits, so lost packets will stay lost while TCP has retransmit > > based on acknowledgements. WHy force this on UDP? > > Because the IP protocol running inside UDP will take care of the > retransmits and if you are doing IPv6 over TCP you will need to reorder > packets, keep connections open, state etc. More precisely, if done over TCP, the results in the event of packet loss would be catastrophic if the IPv6 packet was also TCP. TCP over TCP doesn't work well with packet loss. -- 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 Sep 24 02:37:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13144 for ; Fri, 24 Sep 2004 02:37:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAjhX-0008CT-1E for v6ops-data@psg.com; Fri, 24 Sep 2004 06:37:03 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAjhM-0008BA-32 for v6ops@ops.ietf.org; Fri, 24 Sep 2004 06:36:52 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8O6amL03559; Fri, 24 Sep 2004 09:36:48 +0300 (EET DST) X-Scanned: Fri, 24 Sep 2004 09:36:08 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i8O6a8hH013012; Fri, 24 Sep 2004 09:36:08 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00nbU3jd; Fri, 24 Sep 2004 09:36:06 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i8O6a5Y09826; Fri, 24 Sep 2004 09:36:05 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 09:36:05 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 24 Sep 2004 09:36:04 +0300 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.155.81 172.21.155.81 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok15581.ntc.nokia.com by ESEBE054.noe.nokia.com; 24 Sep 2004 09:36:04 +0300 Subject: Re: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard (fwd) From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Jeroen Massar Cc: EricLKlein , v6ops@ops.ietf.org In-Reply-To: <1096006918.13276.20.camel@firenze.zurich.ibm.com> References: <002401c4a1a8$fbe17150$0401a8c0@ttitelecom.com> <1096006918.13276.20.camel@firenze.zurich.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096007764.4722.25.camel@essrv103nok15581.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 24 Sep 2004 09:36:04 +0300 X-OriginalArrivalTime: 24 Sep 2004 06:36:04.0966 (UTC) FILETIME=[C4434860:01C4A200] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2004-09-24 at 09:21, ext Jeroen Massar wrote: > On Thu, 2004-09-23 at 22:07, EricLKlein wrote: > > General comment: > > As IPv6 does not support NAT in any native form I would like to see the term > > NAT replaced with IPv4 NAT through out the docuement, and a comment at the > > start to the effect that there is no such thing as IPv6 NAT. > > NAT is an IPv4 only thing, there must be no IPv6 NAT, better to not name > it separately IMHO. I do agree with this. > > > > > Final comment: > > I am also unclear why it is assumed that UDP is the prefered protocol. UDP > > has no retransmits, so lost packets will stay lost while TCP has retransmit > > based on acknowledgements. WHy force this on UDP? > > Because the IP protocol running inside UDP will take care of the > retransmits and if you are doing IPv6 over TCP you will need to reorder > packets, keep connections open, state etc. In addition, there are many other implications. These include running tcp over tcp that might produce unpredictable results, running protocol that doesn't need/want retransmissions and would actually suffer from retransmissions - e.g. RTP. Cheers, Jonne. > > Greets, > Jeroen -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Fri Sep 24 03:35:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16273 for ; Fri, 24 Sep 2004 03:35:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAkaW-000JVj-Uc for v6ops-data@psg.com; Fri, 24 Sep 2004 07:33:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAkaL-000JUF-PK for v6ops@ops.ietf.org; Fri, 24 Sep 2004 07:33:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8O7WMe03162; Fri, 24 Sep 2004 10:32:22 +0300 Date: Fri, 24 Sep 2004 10:32:22 +0300 (EEST) From: Pekka Savola To: Salman Asadullah cc: Adeel Ahmed , Ciprian Popoviciu , , Patrick Grossetete Subject: Re: Draft on ISP broad-band deployment scenarios In-Reply-To: <4.3.2.7.2.20040923134651.026cfe20@ce-nfs-1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,INITIAL_INVEST autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Inline... On Thu, 23 Sep 2004, Salman Asadullah wrote: > >There are native deployments today, but AFAIK they have been > >relatively small scale (thousands of users). > > > >The crux is whether the ISP wants to (try to) offer service to *all* > >of its customers, requiring no hardware upgrades or purchases, with no > >assumptions about what the user has deployed -- or just those which > >are OK the assumptions, upgrades/purchases, etc. > > > >I'm concerned that if we focus too much on "native only", only > >(relatively) few users will likely be able to get the service. > > > >It's true that it may be difficult for an ISP to generate revenue out > >of e.g., tunneling based service, offered to anyone, but if some ISP's > >are still interested in this kind of approach, would it be worth > >considering? > > &&& > This is true but we have observed many of the BB ISPs are interested in > deploying native IPv6, driven by new services such as VoD using Multicast > and etc. Some of the examples for these BB ISPs, who are deploying IPv6 > are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in > France, XS4ALL in The Netherlands and etc. Sure. But do these ISPs use a link-layer which supports multicast, e.g., bridged-mode DSL (I think it does..)? That is, if you do something like L2TPoE (which I think many are doing), doesn't that require that multicast transmission be duplicated (on a lower layer) in any case, causing equal amount of traffic as a tunneling based distribution? > Our intent in this draft is to the make the worldwide BB ISP community > aware of possible options available to deploy IPv6 natively today. > > We agree that for some ISPs the native IPv6 solution would not be feasible > due to several reasons as you mentioned previously, with the information > provided in our draft, some ISPs might realize that the extra investment > for a native deployment might make sense for their long term > goals. Besides, for some countries this might be a viable option, think of > Japan, Korea and some other countries where the ISPs are getting tax cuts > from the government, if they deploy IPv6. > &&& Extra investment is always possible, and many will certainly do it. The question is just how the ISPs would transition from "v4-only" to "v4+v6 natively". My argument is that it would be easier for the ISPs to start with tunneling and native v6 where possible, than to require through-out upgrade to native v6. That would reduce the number of up-front investment requirement, but would not prevent from making the investment when it's clear that there will be demand for the service. That would also make it more lucrative to the customers whcih have boxes that don't support v6. They wouldn't have to upgrade immediately to get that service.. > > > >This is one approach, as noted at the start of the message; another is > > > >providing tunneling support. Both could be feasible, depending on > > > >deployment, but the latter is more generic at least. > > > > > > +++++++++++++++ > > > Right, so cable operators currently do provide a GWR which is managed by > > > them. In order > > > to deploy IPv6 the operator can upgrade or replace this GWR with a v6 > > > capable device. > > > +++++++++++++++ > > > >Right. But my practical concern is that if it costs the ISP XXX XXX $ > >to replace the GWR's with ipv6-supporting versions, but XXXX $ (XXX > >XXX >> XXXX) to provide tunneling support, I'd guess most ISPs would > >be interested in going for tunneling first, and just looking at > >replacing GWR's based on their natural EOL schedule. > > &&& > You are correct, the first step in some cases will be tunneling (for > example cable). > > But in other cases BB ISPs are taking the next step and inclined more > towards the native deployments > > Also the extra cost might be justified by the: > > - Services provided and charges ($$ earned) over IPv6 like VoD, video > streaming, IPT and etc. > - Tax cuts received by the governments for IPv6 deployments > - and etc. > &&& See above. I think all services which are available over native v6 can be offered, at least initially, through tunneled v6. If it's still possible to get the service profits, and reduce the amount of initial investment, why wouldn't the ISPs do it? > > > > +++++++++++++++ > > > This is currently a normal practice for Cable Operator's business > > customers. > > > There are only a handful of these customer routes which are summarized and > > > redistributed into the Cable Operator's IGP. This is not really meant for > > > residential > > > customers which account for majority of the customer base. > > > +++++++++++++++ > > > >But what I don't understand is why the business customers would 1) > >need dynamic routing in the first place (what is the actual reason for > >using a routing protocol?), > > &&& > The cable business customers in todays world get a /27 or something > similar. The issue is how does the CMTS keep track of which business > customer owns that particular /27 and how does it get advertised to the > rest of the world. One way to do this is to use static routing but the > problem is that if the cable modem goes down, the CMTS will end up black > holing that traffic and vise versa, thus requiring an IGP. There are > several reasons of using RIPv2, out of which a simple one is that there are > hardly any CM/GWR which support OSPF. But the point is, unless those business customers have backup connectivity, over which they also use the same IGP, the packets will be discarded in any case, so it doesn't seem to matter whether static routing does it whether they are discarded due to lack of a route. The only difference (unless the business is multihomed, and I think you said only few were) is whether the CMTS sends back an ICMP unreachable message to the hosts trying to connect to the business, before it discards the actual packet. That doesn't seem worth the cost & complexity. Further, putting an IGP there will allow business customers to hijack any addresses w/ appropriate prefix advertisements, practically requiring duplicating the ACLs at the CMTS side to allow only the valid prefix. But with the same trouble you could do a static route. > Today's cable deployments uses this, so we had to discuss it in the draft > to make it close to reality. The BB ISP will use RIPng as they were using > RIPv2. We felt this explanation is out of the scope of this document so we > did not include. > &&& It's OK to say they use RIPv2 and thus RIPng seems applicable, but it seems also justified to point the discussion above, that routing protocol is not needed unless you're multihomed or you care a lot about sending ICMP unreachables when the link goes down. It's also worth noting the filtering requirement for the routing protocol, to prevent hijacking. -- 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 Sep 24 04:38:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20237 for ; Fri, 24 Sep 2004 04:38:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAlZL-0006LY-PM for v6ops-data@psg.com; Fri, 24 Sep 2004 08:36:43 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CAlZA-0006H8-Rt for v6ops@ops.ietf.org; Fri, 24 Sep 2004 08:36:33 +0000 Received: (qmail 11330 invoked by uid 417); 24 Sep 2004 08:11:25 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 24 Sep 2004 08:11:25 -0000 Received: from XPNERICK ([132.70.218.240]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Fri, 24 Sep 2004 02:11:23 -0600 Message-ID: <004901c4a20d$f3e76800$0201a8c0@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: <002401c4a1a8$fbe17150$0401a8c0@ttitelecom.com> <1096006918.13276.20.camel@firenze.zurich.ibm.com> Subject: Re: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' toProposed Standard (fwd) Date: Fri, 24 Sep 2004 10:10:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ----- Original Message ----- > From: "Jeroen Massar" > General comment: > > As IPv6 does not support NAT in any native form I would like to see the term > > NAT replaced with IPv4 NAT through out the document, and a comment at the > > start to the effect that there is no such thing as IPv6 NAT. > > NAT is an IPv4 only thing, there must be no IPv6 NAT, better to not name > it separately IMHO. > This is why I think there is a need to be an explicit reference that the need for Teredo is because NAT was depreciated in IPv6, otherwise the question will be raised (if read without referencing this fact) as to why it is not IPv4 NAT to IPv6 NAT. From owner-v6ops@ops.ietf.org Fri Sep 24 04:39:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20306 for ; Fri, 24 Sep 2004 04:39:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAlZa-0006O7-3X for v6ops-data@psg.com; Fri, 24 Sep 2004 08:36:58 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CAlZP-0006Ln-DD for v6ops@ops.ietf.org; Fri, 24 Sep 2004 08:36:47 +0000 Received: (qmail 14165 invoked by uid 417); 24 Sep 2004 08:12:14 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 24 Sep 2004 08:12:14 -0000 Received: from XPNERICK ([132.70.218.240]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Fri, 24 Sep 2004 02:12:12 -0600 Message-ID: <004f01c4a20e$11829970$0201a8c0@ttitelecom.com> From: "EricLKlein" To: v6ops@ops.ietf.org References: Subject: Re: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard (fwd) Date: Fri, 24 Sep 2004 10:11:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thank you all for clarifying my confusion about why UDP. I understand that TCP over TCP is bad. Eric From owner-v6ops@ops.ietf.org Fri Sep 24 06:19:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26855 for ; Fri, 24 Sep 2004 06:19:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAn8e-000P7c-Ow for v6ops-data@psg.com; Fri, 24 Sep 2004 10:17:16 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAn85-000P3Q-8y for v6ops@ops.ietf.org; Fri, 24 Sep 2004 10:16:41 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8OAGdWR003026 for ; Fri, 24 Sep 2004 12:16:40 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Sep 2004 12:16:39 +0200 Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TC4HL8VD; Fri, 24 Sep 2004 12:16:39 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Sep 2004 12:16:39 +0200 Message-ID: X-Sybari-Trust: e0469fd8 74898554 19ebe22a 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: RE: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to Proposed Standard (fwd) Date: Fri, 24 Sep 2004 12:16:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 24 Sep 2004 10:16:39.0686 (UTC) FILETIME=[94C54A60:01C4A21F] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I have trouble reading the following part of Section 5.4.1: "The relay then checks if there is an entry for this IPv6 address in the list of recent Teredo peers, and if the entry is still valid. The relay then performs the following: 1) If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the mapped IPv4 address and mapped UDP port of the entry. The client updates the date of last transmission in the peer entry. 2) If the destination is a Teredo IPv6 address in which the cone bit is set to 1, the packet is sent over UDP to the mapped IPv4 address and mapped UDP port extracted from that IPv6 address. 3) If the destination is a Teredo IPv6 address in which the cone bit is set to 0, the packet is queued. The Teredo relay creates a bubble whose source address is set to a local IPv6 address, and whose destination address is set to the Teredo IPv6 address of the packet's destination. The bubble is sent to the non-null server address corresponding to the Teredo destination. The packet will be de-queued and forwarded when a bubble or another packet will be received from this IPv6 address; if no such packet is received before a time-out of 2 seconds, the Teredo relay may repeat the bubble, up to three times. In cases 2 and 3, the Teredo relay should create a peer entry for the IPv6 address; the entry status is marked as trusted in case 2 (cone NAT), not trusted in case 3. In case 3, if the Teredo relay happens to be located behind a non-cone NAT, it should also send a bubble directly to the mapped IPv4 address and mapped port number of the Teredo destination; this will "open the path" for the return bubble from the Teredo client." Is 1) what is performed if a valid entry exists and 2) and 3) what is performed if a valid entry doesn't exists ? Further what happens when the bubble attempts in 3) fail ? Editorial: In second paragraph on page 31, "Teredo Server" should be replaced by "Teredo Relay", I suppose. BR, Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Pekka Savola > Sent: Thursday, September 23, 2004 7:31 PM > To: v6ops@ops.ietf.org > Subject: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to > Proposed Standard (fwd) > > > FYI. > > ---------- Forwarded message ---------- > Date: Thu, 23 Sep 2004 11:48:50 -0400 > From: The IESG > Reply-To: iesg@ietf.org > To: IETF-Announce > Subject: Last Call: 'Teredo: Tunneling IPv6 over UDP through NATs' to > Proposed Standard > > The IESG has received a request from an individual submitter > to consider the > following document: > > - 'Teredo: Tunneling IPv6 over UDP through NATs' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-10-20. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-02.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > From owner-v6ops@ops.ietf.org Fri Sep 24 13:15:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27938 for ; Fri, 24 Sep 2004 13:15:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CAtbU-00059o-7h for v6ops-data@psg.com; Fri, 24 Sep 2004 17:11:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CAtbJ-00058x-AV for v6ops@ops.ietf.org; Fri, 24 Sep 2004 17:11:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8OHBFx17311 for ; Fri, 24 Sep 2004 20:11:15 +0300 Date: Fri, 24 Sep 2004 20:11:15 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting in Washington, DC, USA (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI -- in case you missed this. ---------- Forwarded message ---------- Date: Fri, 24 Sep 2004 10:04:11 -0400 From: ietf-secretariat@ietf.org To: ietf-announce@ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 61st IETF Meeting in Washington, DC, USA There are two (2) Internet-Draft cutoff dates for the 61st IETF Meeting in Washington, DC, USA: October 18: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions All initial Internet-Drafts (-00) must be submitted by Monday, October 18 at 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday, October 11 at 9:00 AM ET. October 25: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (-01 and higher) must be submitted by Monday, October 25 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, and will have to be resubmitted. Please do not wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, November 08 at 9:00 AM ET, but may not post or announce them until Monday, November 15. 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 61st IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_61.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-v6ops@ops.ietf.org Fri Sep 24 20:12:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03806 for ; Fri, 24 Sep 2004 20:12:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CB08M-000Cye-6K for v6ops-data@psg.com; Sat, 25 Sep 2004 00:09:50 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CB08A-000Ctl-Pz for v6ops@ops.ietf.org; Sat, 25 Sep 2004 00:09:39 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Sep 2004 17:09:47 -0700 X-BrightmailFiltered: true Received: from sasad-w2k01.cisco.com (sjc-vpn3-254.cisco.com [10.21.64.254]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8P09I3d014323; Fri, 24 Sep 2004 17:09:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20040924162002.0267ba60@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Sep 2004 17:09:17 -0700 To: Pekka Savola From: Salman Asadullah Subject: Re: Draft on ISP broad-band deployment scenarios Cc: Adeel Ahmed , Ciprian Popoviciu , , Patrick Grossetete In-Reply-To: References: <4.3.2.7.2.20040923134651.026cfe20@ce-nfs-1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_198860956==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,HTML_MESSAGE, INITIAL_INVEST autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_198860956==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello Pekka, Please see my response between &&&. At 10:32 AM 9/24/2004 +0300, Pekka Savola wrote: >Inline... > >On Thu, 23 Sep 2004, Salman Asadullah wrote: > > >There are native deployments today, but AFAIK they have been > > >relatively small scale (thousands of users). > > > > > >The crux is whether the ISP wants to (try to) offer service to *all* > > >of its customers, requiring no hardware upgrades or purchases, with no > > >assumptions about what the user has deployed -- or just those which > > >are OK the assumptions, upgrades/purchases, etc. > > > > > >I'm concerned that if we focus too much on "native only", only > > >(relatively) few users will likely be able to get the service. > > > > > >It's true that it may be difficult for an ISP to generate revenue out > > >of e.g., tunneling based service, offered to anyone, but if some ISP's > > >are still interested in this kind of approach, would it be worth > > >considering? > > > > &&& > > This is true but we have observed many of the BB ISPs are interested in > > deploying native IPv6, driven by new services such as VoD using Multicast > > and etc. Some of the examples for these BB ISPs, who are deploying IPv6 > > are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in > > France, XS4ALL in The Netherlands and etc. > >Sure. But do these ISPs use a link-layer which supports multicast, >e.g., bridged-mode DSL (I think it does..)? > >That is, if you do something like L2TPoE (which I think many are >doing), doesn't that require that multicast transmission be >duplicated (on a lower layer) in any case, causing equal amount of >traffic as a tunneling based distribution? &&& Well, some might go for L2TPoE but not necessarily. We discussed that option for the sake of completeness and in case some SPs really, really like that model but .... if they do go for L2TPoE then yes, they will not gain much new. On the other hand we talked about the alternatives where the IPv6 traffic is routed while the IPv4 is still L2TPoE. That is for example the case of one of the biggest BB ISP who are providing IPv6 commercial services, where IPv4 is L2TP but IPv6 is routed. They did that for the very reason as they wanted to deploy mcast over it (what you referring to). &&& > > > Our intent in this draft is to the make the worldwide BB ISP community > > aware of possible options available to deploy IPv6 natively today. > > > > We agree that for some ISPs the native IPv6 solution would not be feasible > > due to several reasons as you mentioned previously, with the information > > provided in our draft, some ISPs might realize that the extra investment > > for a native deployment might make sense for their long term > > goals. Besides, for some countries this might be a viable option, think of > > Japan, Korea and some other countries where the ISPs are getting tax cuts > > from the government, if they deploy IPv6. > > &&& > >Extra investment is always possible, and many will certainly do it. >The question is just how the ISPs would transition from "v4-only" to >"v4+v6 natively". My argument is that it would be easier for the ISPs >to start with tunneling and native v6 where possible, than to require >through-out upgrade to native v6. > >That would reduce the number of up-front investment requirement, but >would not prevent from making the investment when it's clear that >there will be demand for the service. > >That would also make it more lucrative to the customers whcih have >boxes that don't support v6. They wouldn't have to upgrade >immediately to get that service.. &&& Ahh .... We totally agree on this and finally understand where you are coming from :-) In order to achieve the above and make this document complete and beneficial for all, we should include the tunneling options as well for remaining environment, FTTH, DSL and Wireless. Tunnelling options for Cable is already discussed (off course we have noted all the comments and feedback which we will address in the next revision of the document). So, we think we would need couple of more things: 1. A general summary section up front stating the intent of the document and available deployment options (tunneling and native). 2. Add a general tunneling section for FTTH, DSL and Wireless sections as another option. We believe this section would be general since we can simply talk about the different tunnelling solutions available and reasons of choosing one or the other and point the reader to the respective tunnel draft/rfc for details. This will make the document complete with both options available in one place for all the BB ISPs. Depending on what stage the BB ISPs are, they can chose whatever they want. Does this sounds like a good plan ? &&& > > > > >This is one approach, as noted at the start of the message; another is > > > > >providing tunneling support. Both could be feasible, depending on > > > > >deployment, but the latter is more generic at least. > > > > > > > > +++++++++++++++ > > > > Right, so cable operators currently do provide a GWR which is > managed by > > > > them. In order > > > > to deploy IPv6 the operator can upgrade or replace this GWR with a v6 > > > > capable device. > > > > +++++++++++++++ > > > > > >Right. But my practical concern is that if it costs the ISP XXX XXX $ > > >to replace the GWR's with ipv6-supporting versions, but XXXX $ (XXX > > >XXX >> XXXX) to provide tunneling support, I'd guess most ISPs would > > >be interested in going for tunneling first, and just looking at > > >replacing GWR's based on their natural EOL schedule. > > > > &&& > > You are correct, the first step in some cases will be tunneling (for > > example cable). > > > > But in other cases BB ISPs are taking the next step and inclined more > > towards the native deployments > > > > Also the extra cost might be justified by the: > > > > - Services provided and charges ($$ earned) over IPv6 like VoD, video > > streaming, IPT and etc. > > - Tax cuts received by the governments for IPv6 deployments > > - and etc. > > &&& > >See above. I think all services which are available over native v6 >can be offered, at least initially, through tunneled v6. If it's >still possible to get the service profits, and reduce the amount of >initial investment, why wouldn't the ISPs do it? &&& Sure. Agreed upon. &&& > > > > > > +++++++++++++++ > > > > This is currently a normal practice for Cable Operator's business > > > customers. > > > > There are only a handful of these customer routes which are > summarized and > > > > redistributed into the Cable Operator's IGP. This is not really > meant for > > > > residential > > > > customers which account for majority of the customer base. > > > > +++++++++++++++ > > > > > >But what I don't understand is why the business customers would 1) > > >need dynamic routing in the first place (what is the actual reason for > > >using a routing protocol?), > > > > &&& > > The cable business customers in todays world get a /27 or something > > similar. The issue is how does the CMTS keep track of which business > > customer owns that particular /27 and how does it get advertised to the > > rest of the world. One way to do this is to use static routing but the > > problem is that if the cable modem goes down, the CMTS will end up black > > holing that traffic and vise versa, thus requiring an IGP. There are > > several reasons of using RIPv2, out of which a simple one is that there > are > > hardly any CM/GWR which support OSPF. > >But the point is, unless those business customers have backup >connectivity, over which they also use the same IGP, the packets will >be discarded in any case, so it doesn't seem to matter whether static >routing does it whether they are discarded due to lack of a route. > >The only difference (unless the business is multihomed, and I think >you said only few were) is whether the CMTS sends back an ICMP >unreachable message to the hosts trying to connect to the business, >before it discards the actual packet. That doesn't seem worth the >cost & complexity. > >Further, putting an IGP there will allow business customers to hijack >any addresses w/ appropriate prefix advertisements, practically >requiring duplicating the ACLs at the CMTS side to allow only the >valid prefix. But with the same trouble you could do a static route. > > > Today's cable deployments uses this, so we had to discuss it in the draft > > to make it close to reality. The BB ISP will use RIPng as they were using > > RIPv2. We felt this explanation is out of the scope of this document so we > > did not include. > > &&& > >It's OK to say they use RIPv2 and thus RIPng seems applicable, but it >seems also justified to point the discussion above, that routing >protocol is not needed unless you're multihomed or you care a lot >about sending ICMP unreachables when the link goes down. It's also >worth noting the filtering requirement for the routing protocol, to >prevent hijacking. &&& Sure. We will incorporate both options in the next revision. Another point to note that in last mile BB environment dual/multi-homed scenarios are hard to find. Cable ISPs use dynamic routing since they find it much more convenient. If they have to configure couple of hundred static routes at each CMTS, in large deployments, it adds up and becomes hard to manage. Again, this is how it is done out there. &&& This has been a great discussion which clarified lot of points and hopefully will make this document to be very beneficial in years to come. We would like to thank you and all the individuals on the list for their interest and valuable feedback (we have received several unicast replies with good points and valuable feedback). We will integrate all the feedback in the next revision. Regards, Salman Asadullah Technical Leader Cisco Systems, Inc. >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --=====================_198860956==_.ALT Content-Type: text/html; charset="us-ascii" Hello Pekka,

Please see my response between &&&.


At 10:32 AM 9/24/2004 +0300, Pekka Savola wrote:
Inline...

On Thu, 23 Sep 2004, Salman Asadullah wrote:
> >There are native deployments today, but AFAIK they have been
> >relatively small scale (thousands of users).
> >
> >The crux is whether the ISP wants to (try to) offer service to *all*
> >of its customers, requiring no hardware upgrades or purchases, with no
> >assumptions about what the user has deployed -- or just those which
> >are OK the assumptions, upgrades/purchases, etc.
> >
> >I'm concerned that if we focus too much on "native only", only
> >(relatively) few users will likely be able to get the service.
> >
> >It's true that it may be difficult for an ISP to generate revenue out
> >of e.g., tunneling based service, offered to anyone, but if some ISP's
> >are still interested in this kind of approach, would it be worth
> >considering?
>
> &&&
> This is true but we have observed many of the BB ISPs are interested in
> deploying native IPv6, driven by new services such as VoD using Multicast
> and etc. Some of the examples for these BB ISPs, who are deploying IPv6
> are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in
> France, XS4ALL in The Netherlands and etc.

Sure. But do these ISPs use a link-layer which supports multicast,
e.g., bridged-mode DSL (I think it does..)?

That is, if you do something like L2TPoE (which I think many are
doing), doesn't that require that multicast transmission be
duplicated (on a lower layer) in any case, causing equal amount of
traffic as a tunneling based distribution?

&&&
Well, some might go for L2TPoE but not necessarily. We discussed that option for the sake of completeness and in case some SPs really, really like that model but .... if they do go for L2TPoE then yes, they will not gain much new. On the other hand we talked about the alternatives where the IPv6 traffic is routed while the IPv4 is still L2TPoE. That is for example the case of one of the biggest BB ISP who are providing IPv6 commercial services, where IPv4 is L2TP but IPv6 is routed. They did that for the very reason as they wanted to deploy mcast over it (what you referring to).
&&&

 
> Our intent in this draft is to the make the worldwide BB ISP community
> aware of possible options available to deploy IPv6 natively today.
>
> We agree that for some ISPs the native IPv6 solution would not be feasible
> due to several reasons as you mentioned previously, with the information
> provided in our draft, some ISPs might realize that the extra investment
> for a native deployment might make sense for their long term
> goals. Besides, for some countries this might be a viable option, think of
> Japan, Korea and some other countries where the ISPs are getting tax cuts
> from the government, if they deploy IPv6.
> &&&

Extra investment is always possible, and many will certainly do it.
The question is just how the ISPs would transition from "v4-only" to
"v4+v6 natively". My argument is that it would be easier for the ISPs
to start with tunneling and native v6 where possible, than to require
through-out upgrade to native v6.

That would reduce the number of up-front investment requirement, but
would not prevent from making the investment when it's clear that
there will be demand for the service.

That would also make it more lucrative to the customers whcih have
boxes that don't support v6. They wouldn't have to upgrade
immediately to get that service..

&&&
Ahh ....

We totally agree on this and finally understand where you are coming from :-)

In order to achieve the above and make this document complete and beneficial for all, we should include the tunneling options as well for remaining environment, FTTH, DSL and Wireless.  Tunnelling options for Cable is already discussed (off course we have noted all the comments and feedback which we will address in the next revision of the document).

So, we think we would need couple of more things:

1. A general summary section up front stating the intent of the document and available deployment options (tunneling and native).
2. Add a general tunneling section for FTTH, DSL and Wireless sections as another option. We believe this section would be general since we can simply talk about the different tunnelling solutions available and reasons of choosing one or the other and point the reader to the respective tunnel draft/rfc for details.

This will make the document complete with both options available in one place for all the BB ISPs.  Depending on what stage the BB ISPs are, they can chose whatever they want.

Does this sounds like a good plan ?
&&&


> > > >This is one approach, as noted at the start of the message; another is
> > > >providing tunneling support. Both could be feasible, depending on
> > > >deployment, but the latter is more generic at least.
> > >
> > > +++++++++++++++
> > > Right, so cable operators currently do provide a GWR which is managed by
> > > them. In order
> > > to deploy IPv6 the operator can upgrade or replace this GWR with a v6
> > > capable device.
> > > +++++++++++++++
> >
> >Right. But my practical concern is that if it costs the ISP XXX XXX $
> >to replace the GWR's with ipv6-supporting versions, but XXXX $ (XXX
> >XXX >> XXXX) to provide tunneling support, I'd guess most ISPs would
> >be interested in going for tunneling first, and just looking at
> >replacing GWR's based on their natural EOL schedule.
>
> &&&
> You are correct, the first step in some cases will be tunneling (for
> example cable).
>
> But in other cases BB ISPs are taking the next step and inclined more
> towards the native deployments
>
> Also the extra cost might be justified by the:
>
> - Services provided and charges ($$ earned) over IPv6 like VoD, video
> streaming, IPT and etc.
> - Tax cuts received by the governments for IPv6 deployments
> - and etc.
> &&&

See above. I think all services which are available over native v6
can be offered, at least initially, through tunneled v6. If it's
still possible to get the service profits, and reduce the amount of
initial investment, why wouldn't the ISPs do it?

&&&
Sure. Agreed upon.
&&&



>
> > > +++++++++++++++
> > > This is currently a normal practice for Cable Operator's business
> > customers.
> > > There are only a handful of these customer routes which are summarized and
> > > redistributed into the Cable Operator's IGP. This is not really meant for
> > > residential
> > > customers which account for majority of the customer base.
> > > +++++++++++++++
> >
> >But what I don't understand is why the business customers would 1)
> >need dynamic routing in the first place (what is the actual reason for
> >using a routing protocol?),
>
> &&&
> The cable business customers in todays world get a /27 or something
> similar. The issue is how does the CMTS keep track of which business
> customer owns that particular /27 and how does it get advertised to the
> rest of the world. One way to do this is to use static routing but the
> problem is that if the cable modem goes down, the CMTS will end up black
> holing that traffic and vise versa, thus requiring an IGP. There are
> several reasons of using RIPv2, out of which a simple one is that there are
> hardly any CM/GWR which support OSPF.

But the point is, unless those business customers have backup
connectivity, over which they also use the same IGP, the packets will
be discarded in any case, so it doesn't seem to matter whether static
routing does it whether they are discarded due to lack of a route.

The only difference (unless the business is multihomed, and I think
you said only few were) is whether the CMTS sends back an ICMP
unreachable message to the hosts trying to connect to the business,
before it discards the actual packet. That doesn't seem worth the
cost & complexity.

Further, putting an IGP there will allow business customers to hijack
any addresses w/ appropriate prefix advertisements, practically
requiring duplicating the ACLs at the CMTS side to allow only the
valid prefix. But with the same trouble you could do a static route.
 
> Today's cable deployments uses this, so we had to discuss it in the draft
> to make it close to reality. The BB ISP will use RIPng as they were using
> RIPv2. We felt this explanation is out of the scope of this document so we
> did not include.
> &&&

It's OK to say they use RIPv2 and thus RIPng seems applicable, but it
seems also justified to point the discussion above, that routing
protocol is not needed unless you're multihomed or you care a lot
about sending ICMP unreachables when the link goes down. It's also
worth noting the filtering requirement for the routing protocol, to
prevent hijacking.

&&&
Sure. We will incorporate both options in the next revision.

Another point to note that in last mile BB environment dual/multi-homed scenarios are hard to find.  Cable ISPs use dynamic routing since they find it much more convenient.  If they have to configure couple of hundred static routes at each CMTS, in large deployments, it adds up and becomes hard to manage.  Again, this is how it is done out there.
&&&

This has been a great discussion which clarified lot of points and hopefully will make this document to be very beneficial in years to come.

We would like to thank you and all the individuals on the list for their interest and valuable feedback (we have received several unicast replies with good points and valuable feedback).

We will integrate all the feedback in the next revision.

Regards,
Salman Asadullah
Technical Leader
Cisco Systems, Inc.


--
Pekka Savola                "You each name yourselves king, yet the
Netcore Oy                   kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=====================_198860956==_.ALT-- From owner-v6ops@ops.ietf.org Mon Sep 27 05:22:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14696 for ; Mon, 27 Sep 2004 05:22:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CBreV-000OVs-A4 for v6ops-data@psg.com; Mon, 27 Sep 2004 09:18:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CBreK-000OUn-2E for v6ops@ops.ietf.org; Mon, 27 Sep 2004 09:18:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8R9Hq901187; Mon, 27 Sep 2004 12:17:52 +0300 Date: Mon, 27 Sep 2004 12:17:52 +0300 (EEST) From: Pekka Savola To: Salman Asadullah cc: Adeel Ahmed , Ciprian Popoviciu , , Patrick Grossetete Subject: Re: Draft on ISP broad-band deployment scenarios In-Reply-To: <4.3.2.7.2.20040924162002.0267ba60@ce-nfs-1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 24 Sep 2004, Salman Asadullah wrote: > > > &&& > > > This is true but we have observed many of the BB ISPs are interested in > > > deploying native IPv6, driven by new services such as VoD using Multicast > > > and etc. Some of the examples for these BB ISPs, who are deploying IPv6 > > > are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in > > > France, XS4ALL in The Netherlands and etc. > > > >Sure. But do these ISPs use a link-layer which supports multicast, > >e.g., bridged-mode DSL (I think it does..)? > > > >That is, if you do something like L2TPoE (which I think many are > >doing), doesn't that require that multicast transmission be > >duplicated (on a lower layer) in any case, causing equal amount of > >traffic as a tunneling based distribution? > > &&& > Well, some might go for L2TPoE but not necessarily. We discussed that > option for the sake of completeness and in case some SPs really, really > like that model but .... if they do go for L2TPoE then yes, they will not > gain much new. On the other hand we talked about the alternatives where the > IPv6 traffic is routed while the IPv4 is still L2TPoE. That is for example > the case of one of the biggest BB ISP who are providing IPv6 commercial > services, where IPv4 is L2TP but IPv6 is routed. They did that for the very > reason as they wanted to deploy mcast over it (what you referring to). > &&& Right. This consideration wrt. multicast might be worth spelling out somewhere. > >Extra investment is always possible, and many will certainly do it. > >The question is just how the ISPs would transition from "v4-only" to > >"v4+v6 natively". My argument is that it would be easier for the ISPs > >to start with tunneling and native v6 where possible, than to require > >through-out upgrade to native v6. > > > >That would reduce the number of up-front investment requirement, but > >would not prevent from making the investment when it's clear that > >there will be demand for the service. > > > >That would also make it more lucrative to the customers whcih have > >boxes that don't support v6. They wouldn't have to upgrade > >immediately to get that service.. > > &&& > Ahh .... > > We totally agree on this and finally understand where you are coming > from :-) Great :) > In order to achieve the above and make this document complete and > beneficial for all, we should include the tunneling options as well for > remaining environment, FTTH, DSL and Wireless. Tunnelling options for > Cable is already discussed (off course we have noted all the comments and > feedback which we will address in the next revision of the document). > > So, we think we would need couple of more things: > > 1. A general summary section up front stating the intent of the document > and available deployment options (tunneling and native). > > 2. Add a general tunneling section for FTTH, DSL and Wireless sections as > another option. We believe this section would be general since we can > simply talk about the different tunnelling solutions available and reasons > of choosing one or the other and point the reader to the respective tunnel > draft/rfc for details. > > This will make the document complete with both options available in one > place for all the BB ISPs. Depending on what stage the BB ISPs are, they > can chose whatever they want. > > Does this sounds like a good plan ? > &&& Sounds like a good approach. Note that the choice probably also depends a lot on what the BB ISP thinks their customers' status (and willingness) wrt. IPv6 support is. If the customers employ a lot of NAT boxes or similar, they might have to take these scenarios into account as well, and provide a tunnel service to those people. > >It's OK to say they use RIPv2 and thus RIPng seems applicable, but it > >seems also justified to point the discussion above, that routing > >protocol is not needed unless you're multihomed or you care a lot > >about sending ICMP unreachables when the link goes down. It's also > >worth noting the filtering requirement for the routing protocol, to > >prevent hijacking. > > &&& > Sure. We will incorporate both options in the next revision. > > Another point to note that in last mile BB environment dual/multi-homed > scenarios are hard to find. Cable ISPs use dynamic routing since they find > it much more convenient. If they have to configure couple of hundred > static routes at each CMTS, in large deployments, it adds up and becomes > hard to manage. Again, this is how it is done out there. > &&& > > This has been a great discussion which clarified lot of points and > hopefully will make this document to be very beneficial in years to come. > > We would like to thank you and all the individuals on the list for their > interest and valuable feedback (we have received several unicast replies > with good points and valuable feedback). > > We will integrate all the feedback in the next revision. Thanks! -- 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 Mon Sep 27 05:27:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14894 for ; Mon, 27 Sep 2004 05:27:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CBrma-000PHE-8y for v6ops-data@psg.com; Mon, 27 Sep 2004 09:26:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CBrmP-000PGD-51 for v6ops@ops.ietf.org; Mon, 27 Sep 2004 09:26:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8R9QfN01345; Mon, 27 Sep 2004 12:26:41 +0300 Date: Mon, 27 Sep 2004 12:26:41 +0300 (EEST) From: Pekka Savola To: "Karen E. Nielsen (AH/TED)" cc: V6OPS WG , "'Radhakrishnan Suryanarayanan'" , , "'Soininen Jonne (Nokia-NET/Helsinki)'" Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I've tried to figure out how to close this thread but I haven't had much success yet.. :/ On Wed, 22 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > > As for my personal take -- hopefully I've understood the arguments > > properly.. > > > > If you receive IPv4 ICMP error messages relating to an IPv6-in-IPv4 > > tunnel, one should probably do something if it's possible, because > > that will be an indication that IPv6 link layer has failed (and that > > particular error can be propagated the same way as any other IPv6 link > > failure, or by direct ICMP message conversion). > > > > What and whether the implementations must treat IPv4 ICMP error > > messages somehow depends on the mechanism in question. > > draft-ietf-v6ops-mech-v2-06.txt does not mandate it for static MTU > > discovery, but it's obviously required for dynamic MTU discovery. > > 6to4 spec (section 7) doesn't require it either, but seems to imply > > that it can be done. > > > > So, as to the issue whether tunnel servers need to be able to send > > back ICMPv6 error messages if the implementation thinks that the link > > has failed, I'd say "yes, it probably should" because shouldn't all > > IPv6 nodes be supposed to be able to do something like that. The > > issue then is what constitutes good indication for "link failure" > > (e.g., in this case, IPv4 tunneling failing). Specifying what that > > must or should include is probably mechanism-dependent. > > > The tunnel servers are in many respects replacing IPv6 access routers, > for which we have explicit requirements in this respect, i.e., > SHOULD perform IPv6 NUD. > > If I understand you correctly you seem to be saying that not only > is it up for the individual tunnel mechanism to decide how to perform > determination of link-failure (with that, I agree completely) Yes. > - but also (?) that it is up to the individual mechanism to determine > what constitutes indication of link failure, and thus consequently, > which kind of link failures that it will seek to monitor and report - !! Yes, this is what I meant. This stems from the practical point of view that it's a bit difficult for us (well, we could create a draft or RFC) to create a "policy" on that, to be followed by transition mechanisms to come. The typical, pragmatic approach is to look each proposition and try to figure out whether it is justified or not. > I may not disagree with the latter, but if this is the route that we > want to take, I would like it us to do it with our "eyes wide open" > so to speak - saying clearly that in the areas of IPv6 black hole > detection, tunnel servers may not provide a service comparatively > with the native IPv6 one. Black hole detection is indeed a problem, but luckily enough, the problem is already commonplace, both in v4 (e.g., firewalling without ICMP transmissions on rejects) and (to a degree) in v6. Therefore, if you want to build a very robust application, you'll have to deal with black holes in any case. However, the vast majority of apps won't consider this a sufficiently wide problem. That being said, I think it would be very useful to try to keep the original NUD & ICMP characteristics of IPv6 in the tunneling mechanisms that are specified, if not for other reason than providing a good and quick indication of network blockage to the apps. But that seems to be a tradeoff which needs to be weighted per transition mechanism. I'd certainly like to default to specifying similar NUD processes, unless otherwise justified, though. -- 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 Mon Sep 27 05:30:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15087 for ; Mon, 27 Sep 2004 05:30:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CBrpo-000PgT-JB for v6ops-data@psg.com; Mon, 27 Sep 2004 09:30:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CBrpV-000Paj-9m for v6ops@ops.ietf.org; Mon, 27 Sep 2004 09:29:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8R9Tt501422 for ; Mon, 27 Sep 2004 12:29:55 +0300 Date: Mon, 27 Sep 2004 12:29:55 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Folks, (co-chair hat on) There haven't been any reviews on the list. That's not good. We need the reviews to make this go forward. Otherwise we cannot go forward with this, and we cannot go forward with the transition mechanisms for the enterprises. PLEASE provide feedback ASAP! (co-chair hat off) ---------- Forwarded message ---------- Date: Sat, 18 Sep 2004 21:24:32 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Hi, (co-chair hat on) This is the initial draft on Enterprise network analysis, and is still being improved. We need input from the WG to make it better. Please read and comment ASAP, preferably within a week. We hope to get this in the shape for WG last call reasonably soon. Again, please send feedback. This is very important work! (hat off) On Thu, 16 Sep 2004 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 Enterprise Network Analysis > Author(s) : J. Bound, et al. > Filename : draft-ietf-v6ops-ent-analysis-00.txt > Pages : 30 > Date : 2004-9-16 > > This document analyzes the transition to IPv6 in enterprise > networks. These networks are characterized as a network that has > multiple internal links, one or more router connections, to one or > more Providers, and is managed by a network operations entity. The > analysis will focus on a base set of transition units and > requirements expanded from a previous Enterprise Scenarios > document, and will depict a set of components and transition > methods required for the enterprise to transition to IPv6 within > each scenario and then common to all scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-00.txt [...] From owner-v6ops@ops.ietf.org Tue Sep 28 04:48:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06757 for ; Tue, 28 Sep 2004 04:48:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CCDc0-000EI3-6b for v6ops-data@psg.com; Tue, 28 Sep 2004 08:45:28 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CCDbe-000EFa-Hx for v6ops@ops.ietf.org; Tue, 28 Sep 2004 08:45:07 +0000 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8S8j5WR008483 for ; Tue, 28 Sep 2004 10:45:05 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 28 Sep 2004 10:45:05 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TC4YY3BT; Tue, 28 Sep 2004 10:45:05 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Sep 2004 10:45:04 +0200 Message-ID: X-Sybari-Trust: a17d4431 47b3073a 3756a41f 00000138 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" Cc: V6OPS WG , "'Radhakrishnan Suryanarayanan'" , juha.wiljakka@nokia.com, "'Soininen Jonne (Nokia-NET/Helsinki)'" Subject: RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft Date: Tue, 28 Sep 2004 10:44:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 28 Sep 2004 08:45:05.0298 (UTC) FILETIME=[73833720:01C4A537] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, It seems that we are converging against a resolution, which is: In the area of IPv6 black hole detection, tunnel servers may not provide a service comparatively with the native IPv6 one. Ideally, IPv6 transition/tunnelling mechanisms should provide black hole detection mechanisms similar to original IPv6 NUD processes. Whether such are provided, however, will for the individual transition mechanism be a tradeoff weighting the implementation aspects and the anticipated deployment environment aspects against the added value of such IPv6 NUD like processes. (-??) I can live with that. BR, Karen > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, September 27, 2004 11:27 AM > To: Karen E. Nielsen (AH/TED) > Cc: V6OPS WG; 'Radhakrishnan Suryanarayanan'; juha.wiljakka@nokia.com; > 'Soininen Jonne (Nokia-NET/Helsinki)' > Subject: RE: Unreachability detection at tunnels servers WAS: RE: > Comments on zeroconf draft > > > I've tried to figure out how to close this thread but I haven't had > much success yet.. :/ > > On Wed, 22 Sep 2004, Karen E. Nielsen (AH/TED) wrote: > > > As for my personal take -- hopefully I've understood the > arguments > > > properly.. > > > > > > If you receive IPv4 ICMP error messages relating to an > IPv6-in-IPv4 > > > tunnel, one should probably do something if it's possible, because > > > that will be an indication that IPv6 link layer has > failed (and that > > > particular error can be propagated the same way as any > other IPv6 link > > > failure, or by direct ICMP message conversion). > > > > > > What and whether the implementations must treat IPv4 ICMP error > > > messages somehow depends on the mechanism in question. > > > draft-ietf-v6ops-mech-v2-06.txt does not mandate it for static MTU > > > discovery, but it's obviously required for dynamic MTU > discovery. > > > 6to4 spec (section 7) doesn't require it either, but > seems to imply > > > that it can be done. > > > > > > So, as to the issue whether tunnel servers need to be able to send > > > back ICMPv6 error messages if the implementation thinks > that the link > > > has failed, I'd say "yes, it probably should" because > shouldn't all > > > IPv6 nodes be supposed to be able to do something like that. The > > > issue then is what constitutes good indication for "link > failure" > > > (e.g., in this case, IPv4 tunneling failing). Specifying > what that > > > must or should include is probably mechanism-dependent. > > > > > > The tunnel servers are in many respects replacing IPv6 > access routers, > > for which we have explicit requirements in this respect, i.e., > > SHOULD perform IPv6 NUD. > > > > If I understand you correctly you seem to be saying that not only > > is it up for the individual tunnel mechanism to decide how > to perform > > determination of link-failure (with that, I agree completely) > > Yes. > > > - but also (?) that it is up to the individual mechanism to > determine > > what constitutes indication of link failure, and thus consequently, > > which kind of link failures that it will seek to monitor > and report - !! > > Yes, this is what I meant. > > This stems from the practical point of view that it's a bit difficult > for us (well, we could create a draft or RFC) to create a "policy" on > that, to be followed by transition mechanisms to come. The typical, > pragmatic approach is to look each proposition and try to figure out > whether it is justified or not. > > > I may not disagree with the latter, but if this is the route that we > > want to take, I would like it us to do it with our "eyes wide open" > > so to speak - saying clearly that in the areas of IPv6 black hole > > detection, tunnel servers may not provide a service comparatively > > with the native IPv6 one. > > Black hole detection is indeed a problem, but luckily enough, the > problem is already commonplace, both in v4 (e.g., firewalling without > ICMP transmissions on rejects) and (to a degree) in v6. Therefore, if > you want to build a very robust application, you'll have to deal with > black holes in any case. However, the vast majority of apps won't > consider this a sufficiently wide problem. > > That being said, I think it would be very useful to try to keep the > original NUD & ICMP characteristics of IPv6 in the tunneling > mechanisms that are specified, if not for other reason than providing > a good and quick indication of network blockage to the apps. But that > seems to be a tradeoff which needs to be weighted per transition > mechanism. I'd certainly like to default to specifying similar NUD > processes, unless otherwise justified, though. > > -- > 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 Wed Sep 29 00:29:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24000 for ; Wed, 29 Sep 2004 00:29:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CCW2J-000Fuc-4C for v6ops-data@psg.com; Wed, 29 Sep 2004 04:25:51 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CCR25-0007tj-DB for v6ops@ops.ietf.org; Tue, 28 Sep 2004 23:05:17 +0000 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i8SN3DJ03995; Tue, 28 Sep 2004 16:03:13 -0700 (PDT) Message-Id: <200409282303.i8SN3DJ03995@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 3904 on Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 28 Sep 2004 16:03:13 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-17.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3904 Title: Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks Author(s): C. Huitema, R. Austein, S. Satapati, R. van der Pol Status: Informational Date: September 2004 Mailbox: huitema@microsoft.com, sra@isc.org, satapati@cisco.com, Ronald.vanderPol@nlnetlabs.nl Pages: 19 Characters: 46844 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-unmaneval-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3904.txt This document analyzes issues involved in the transition of "unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040928160151.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3904 --OtherAccess Content-Type: Message/External-body; name="rfc3904.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040928160151.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Sep 29 12:41:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18150 for ; Wed, 29 Sep 2004 12:41:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CChT6-000NjB-MT for v6ops-data@psg.com; Wed, 29 Sep 2004 16:38:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CChSv-000Ngb-H9 for v6ops@ops.ietf.org; Wed, 29 Sep 2004 16:38:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8TGc3L12693 for ; Wed, 29 Sep 2004 19:38:03 +0300 Date: Wed, 29 Sep 2004 19:38:02 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Going forward with zero-config tunneling requirement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) There has been some discussion on whether the zero-config tunneling requirements document should be specific to 3GPP or not. Assisted tunneling document also includes some discussion overlapping this problem space. These issues will need to be resolved to make progress. (i.e., draft-nielsen-v6ops-zeroconf-goals-01.txt + draft-ietf-v6ops-assisted-tunneling-requirements-00.txt) People who have commented on this seem to have reached (off-list) consensus that draft-nielsen should be revised to be more explicitly 3GPP -specific, the 'simple' mode should be removed from assisted tunneling requirements, and a new document, discussing the the more general 'zero-config' problem space (ISP/unmanaged, possibly enterprise) should be written. (The primary alternative would have been to expand draft-nielsen's scope to include all the zero-config tunneling scenarios.) The goal is to be able to revise or write the documents ASAP, adopt them as WG documents, and proceed to WG last calls as appropriate quickly. If you have comments about this direction, want to volunteer to help, etc. -- please speak up ASAP either on- or off-list as appropriate. (hat off) -- 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 Wed Sep 29 19:44:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02900 for ; Wed, 29 Sep 2004 19:44:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CCo5W-000Nuk-26 for v6ops-data@psg.com; Wed, 29 Sep 2004 23:42:22 +0000 Received: from [195.130.132.57] (helo=apate.telenet-ops.be) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CCo5K-000Nqk-UE for v6ops@ops.ietf.org; Wed, 29 Sep 2004 23:42:11 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id C5E88248048 for ; Thu, 30 Sep 2004 01:42:09 +0200 (MEST) Received: from gnoc1.sinfilo.com (C3828133.kabel.telenet.be [195.130.129.51]) by apate.telenet-ops.be (Postfix) with ESMTP id AAD45248044 for ; Thu, 30 Sep 2004 01:42:09 +0200 (MEST) Received: from [10.1.53.111] ([10.1.53.111]) by gnoc1.sinfilo.com (8.12.10/8.12.10) with ESMTP id i8TNZjQP010391 for ; Wed, 29 Sep 2004 23:35:45 GMT User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 30 Sep 2004 01:41:59 +0200 Subject: Re: Going forward with zero-config tunneling requirement From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, all, I'm not really convinced about this view. My vision is: 1) Assisted tunneling will basically help to services like what we today generally know as Tunnel Brokers. This provides the more feature-rich option. 2) Then we have the need for a zero configuration in 3GPP environment, which explicitly excludes NAT traversal. 3) Finally we have the need for a zero configuration in non-3GPP environments, which will require NAT traversal. My view actually is that 2 & 3 could be the same, specially because in the real world I've seen GPRS deployment both with no-NAT (public addresses) and using NAT (with private addresses). But in the later case, NAT traversal was not required because proto-41 forwarding worked. Of course, this may be not the case all the time ! I also understand that having a zero configuration solution w/o NAT traversal could be technically very difficult and probably will mean that the solution will not be "simple" as required by 3GPP (no new "whatever" in the existing infrastructure). Of course, everything needs to be balanced and considered. The question here is probably to have the reply to "will all the 3GPP deployments forward 41 even when using NAT ?". Can any of the experts on this have an answer ? Finally, my opinion is that a single document can take both 3GPP and non-3GPP zeroconfig, but may be we need to progress a little bit on the solution or candidate solutions to assert that ? In the worst case, I can live also having 2 requirement documents and 2 solutions. I'm already working on those topics, and of course, will be available to continue working on that, and happy to start a non-3GPP document/s if that's the WG decision. Regards, Jordi > Hi, > > (co-chair hat on) > > There has been some discussion on whether the zero-config tunneling > requirements document should be specific to 3GPP or not. Assisted > tunneling document also includes some discussion overlapping this > problem space. These issues will need to be resolved to make > progress. > > (i.e., draft-nielsen-v6ops-zeroconf-goals-01.txt + > draft-ietf-v6ops-assisted-tunneling-requirements-00.txt) > > People who have commented on this seem to have reached (off-list) > consensus that draft-nielsen should be revised to be more explicitly > 3GPP -specific, the 'simple' mode should be removed from assisted > tunneling requirements, and a new document, discussing the the more > general 'zero-config' problem space (ISP/unmanaged, possibly > enterprise) should be written. > > (The primary alternative would have been to expand > draft-nielsen's scope to include all the zero-config tunneling > scenarios.) > > The goal is to be able to revise or write the documents ASAP, adopt > them as WG documents, and proceed to WG last calls as appropriate > quickly. > > If you have comments about this direction, want to volunteer to help, > etc. -- please speak up ASAP either on- or off-list as appropriate. > > (hat off) From owner-v6ops@ops.ietf.org Thu Sep 30 02:02:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02403 for ; Thu, 30 Sep 2004 02:02:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CCtyP-000IJT-3H for v6ops-data@psg.com; Thu, 30 Sep 2004 05:59:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CCtyE-000IGY-4M for v6ops@ops.ietf.org; Thu, 30 Sep 2004 05:59:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8U5x9N30878; Thu, 30 Sep 2004 08:59:09 +0300 Date: Thu, 30 Sep 2004 08:59:09 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jordi, I think you were missing one assumption about 3GPP, that their solution would only be needed when there is no NAT traversal or proto-41 forwarding, i.e., the 3GPP operator provides the tunnel endpoint. If that's not the case, all bets are off. Below.. On Thu, 30 Sep 2004, JORDI PALET MARTINEZ wrote: > My view actually is that 2 & 3 could be the same, specially because > in the real world I've seen GPRS deployment both with no-NAT (public > addresses) and using NAT (with private addresses). But in the later > case, NAT traversal was not required because proto-41 forwarding > worked. Of course, this may be not the case all the time ! > > I also understand that having a zero configuration solution w/o NAT > traversal could be technically very difficult and probably will mean that > the solution will not be "simple" as required by 3GPP (no new "whatever" in > the existing infrastructure). Of course, everything needs to be balanced and > considered. The assumption of '3GPP' case is that even if private addresses are used, there is no need for NAT traversal, because the zero-configuration tunnel server is provided in the 3GPP network, i.e., in the same 'addressing domain'. The zero-configuration solution for 3GPP does not try to solve the case where the 3GPP operator does not provide the tunnel endpoint. [Karen: maybe this should be made more explicit in the requirements] That would be rather close to the 'ISP' zero-config situation. (FWIW, I think it's certainly a consideration whether a 3GPP UE could work even when the 3GPP operator does not provide this capability, or in an enterprise's WLAN environment, or whatever -- in that sense, having a more generic solution would seem to be rather helpful. But that's something that needs to be debated later.) > Finally, my opinion is that a single document can take both 3GPP and > non-3GPP zeroconfig, but may be we need to progress a little bit on the > solution or candidate solutions to assert that ? Could be (I personally thought so), but there was reluctance to this, but we need to make progress in the requirements, and this is one approach to accomplish it. -- 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 Thu Sep 30 03:22:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21586 for ; Thu, 30 Sep 2004 03:22:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CCvF6-0002Qw-Rf for v6ops-data@psg.com; Thu, 30 Sep 2004 07:20:44 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CCvEd-0002Mh-9b for v6ops@ops.ietf.org; Thu, 30 Sep 2004 07:20:15 +0000 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i8U7KEfM016955 for ; Thu, 30 Sep 2004 09:20:14 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Sep 2004 09:20:13 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TNGLSLAP; Thu, 30 Sep 2004 09:20:13 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Sep 2004 09:20:13 +0200 Message-ID: X-Sybari-Trust: 428cbfd6 74898554 4251586b 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Pekka Savola'" , JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Subject: RE: Going forward with zero-config tunneling requirement Date: Thu, 30 Sep 2004 09:20:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 Sep 2004 07:20:13.0358 (UTC) FILETIME=[ED4E54E0:01C4A6BD] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, Jordi, > > Jordi, > > I think you were missing one assumption about 3GPP, that their > solution would only be needed when there is no NAT traversal or > proto-41 forwarding, i.e., the 3GPP operator provides the tunnel > endpoint. If that's not the case, all bets are off. Below.. > > On Thu, 30 Sep 2004, JORDI PALET MARTINEZ wrote: > > My view actually is that 2 & 3 could be the same, specially because > > in the real world I've seen GPRS deployment both with no-NAT (public > > addresses) and using NAT (with private addresses). But in the later > > case, NAT traversal was not required because proto-41 forwarding > > worked. Of course, this may be not the case all the time ! > > > > I also understand that having a zero configuration solution w/o NAT > > traversal could be technically very difficult and probably > will mean that > > the solution will not be "simple" as required by 3GPP (no > new "whatever" in > > the existing infrastructure). Of course, everything needs > to be balanced and > > considered. > > The assumption of '3GPP' case is that even if private addresses are > used, there is no need for NAT traversal, because the > zero-configuration tunnel server is provided in the 3GPP network, > i.e., in the same 'addressing domain'. > > The zero-configuration solution for 3GPP does not try to solve the > case where the 3GPP operator does not provide the tunnel endpoint. > [Karen: maybe this should be made more explicit in the requirements] > Agreed. Especially now that we are restricting the doc to this case only. > That would be rather close to the 'ISP' zero-config situation. > > (FWIW, I think it's certainly a consideration whether a 3GPP UE could > work even when the 3GPP operator does not provide this capability, or > in an enterprise's WLAN environment, or whatever -- in that sense, > having a more generic solution would seem to be rather helpful. But > that's something that needs to be debated later.) > > > Finally, my opinion is that a single document can take both 3GPP and > > non-3GPP zeroconfig, but may be we need to progress a > little bit on the > > solution or candidate solutions to assert that ? > > Could be (I personally thought so), but there was reluctance to this, > but we need to make progress in the requirements, and this is one > approach to accomplish it. > By referencing to the 3GPP case, the new zeroconfig document does not explicit exclude the 3GPP case. To me then we are simply isolating the 3GPP case first and foremost because of its critical timing requirements. To what extend it deserves to be isolated also from a pure technical perspective remains to be seen.. BR, Karen From owner-v6ops@ops.ietf.org Thu Sep 30 12:44:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08189 for ; Thu, 30 Sep 2004 12:44:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CD40V-000LKD-U3 for v6ops-data@psg.com; Thu, 30 Sep 2004 16:42:15 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CD40D-000LJ4-A7 for v6ops@ops.ietf.org; Thu, 30 Sep 2004 16:41:57 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i8UGfm4d009744; Thu, 30 Sep 2004 09:41:49 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i8UGfkJQ021783; Thu, 30 Sep 2004 18:41:47 +0200 (MEST) Message-ID: <415C3771.4020702@sun.com> Date: Thu, 30 Sep 2004 09:42:25 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > People who have commented on this seem to have reached (off-list) > consensus that draft-nielsen should be revised to be more explicitly > 3GPP -specific, the 'simple' mode should be removed from assisted > tunneling requirements, and a new document, discussing the the more > general 'zero-config' problem space (ISP/unmanaged, possibly > enterprise) should be written. I don't understand what this would mean. I don't think we want a 3GPP specific (simple) tunneling mechanism, which is incapable to work across v4NATs, while the generic tunneling mechanism (which can work across NATs) is prohibited from having a simple mode i.e. a mode which doesn't require pre-registration. But when reading the paragraph above that seems to be what you are saying :-( Did you intend to say something else? The other big picture thing I don't understand is this space is the issue about handling IPv4 NATs. The 3GPP specific requirements do not require working across a NAT, which makes sense. But I see this being used as an argument that 3GPP needs a solution which is incapable of working across a NAT, which makes no sense at all; if there is a solution which satisfies the 3GPP requirements as stated, then whether that solution satisfies additional requirements should be ok. Erik From owner-v6ops@ops.ietf.org Thu Sep 30 12:54:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09364 for ; Thu, 30 Sep 2004 12:54:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CD4B6-000Mq6-8M for v6ops-data@psg.com; Thu, 30 Sep 2004 16:53:12 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CD4Av-000Mox-3d for v6ops@ops.ietf.org; Thu, 30 Sep 2004 16:53:01 +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 i8UGqqgg020741; Thu, 30 Sep 2004 17:52:52 +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 RAA23595; Thu, 30 Sep 2004 17:52:48 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i8UGqmi01346; Thu, 30 Sep 2004 17:52:48 +0100 Date: Thu, 30 Sep 2004 17:52:48 +0100 From: Tim Chown To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement Message-ID: <20040930165248.GI32021@login.ecs.soton.ac.uk> Mail-Followup-To: Pekka Savola , v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Sep 29, 2004 at 07:38:02PM +0300, Pekka Savola wrote: > > (i.e., draft-nielsen-v6ops-zeroconf-goals-01.txt + Karen's draft doesn't specifically mention the 3GPP specific assumptions in the draft in Section 4.2 (i.e. TEP in the provider network, with or without private IPv4 addresses used, no NAT traversal required, etc). However, she does mention "no-NAT" in section 4.1, and the assumptions in 4.1 are really kind of defining the 3GPP scenario... so the text of 4.2 seems to become a little redundant. Essentially the assumptions of 4.1 define the scenario. Thus one solution is to rework section 4 to define the scenarios, as others have hinted or suggested. So what are those scenarios? Using the four v6ops transition scenarios of 3gpp, unmanaged, enterprise and isp seems sensible. For 3gpp, we already have the scenario for zct within the 3gpp provider For enterprise, can we assume the zct is also within the enterprise? My feeling is yes. So the scenario is very similar. For umanaged (=soho largely), the zct would not be within the soho network, rather from a host in the soho network to some external service. This probably brings in NAT traversal, etc. In this case, perhaps we should only be considering assisted tunnelling. For isp, I'm not sure zct has any real meaning. Thus (unless we have other broad scenarios?) we should push Karen's draft for 3gpp and enterprise, and assisting tunnelling for unmanaged. This could be documented in a reworked section 4 of Karen's draft? Let's not try to dive down unnecessary ratholes here :) Tim PS. If there are other broad scenarios, we should do the v6ops analysis for them for transition...(!) From owner-v6ops@ops.ietf.org Thu Sep 30 13:06:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10449 for ; Thu, 30 Sep 2004 13:06:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CD4N1-000P6h-Gw for v6ops-data@psg.com; Thu, 30 Sep 2004 17:05:31 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CD4Mq-000P3Y-HY for v6ops@ops.ietf.org; Thu, 30 Sep 2004 17:05:20 +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 i8UH5Jgg021025 for ; Thu, 30 Sep 2004 18:05:19 +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 SAA24037 for ; Thu, 30 Sep 2004 18:05:16 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i8UH5FG01586 for v6ops@ops.ietf.org; Thu, 30 Sep 2004 18:05:15 +0100 Date: Thu, 30 Sep 2004 18:05:15 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement Message-ID: <20040930170515.GJ32021@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <415C3771.4020702@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <415C3771.4020702@sun.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Sep 30, 2004 at 09:42:25AM -0700, Erik Nordmark wrote: > > The other big picture thing I don't understand is this space is the > issue about handling IPv4 NATs. > > The 3GPP specific requirements do not require working across a NAT, > which makes sense. But I see this being used as an argument that 3GPP > needs a solution which is incapable of working across a NAT, which makes > no sense at all; if there is a solution which satisfies the 3GPP > requirements as stated, then whether that solution satisfies additional > requirements should be ok. But the 3gpp (and probably? enterprise) zct solution would be simpler for not needing to support NAT traversal or proto 41 issues? It seems the 3gpp community would also like a simple solution available quickly (i.e. yesterday :) and thus pontificating over a more complex solution would probably only lead to the 3gpp people developing the simple solution anyway, outside the IETF process? I think NAT traversal is adding complexity. If there was a simple, standards based way to do NAT traversal now, then emerging IPv6 tunnel brokers would be using it. While TSP is nice, when it comes to implementing a tunnel broker, this is the trickiest aspect to its design (dynamic IPv4 being another tricky - though less so - aspect). I appreciate minimising the number of solutions is desirable, is there any deployment problem having both zct and zct++ solutions? -- Tim From owner-v6ops@ops.ietf.org Thu Sep 30 13:47:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13415 for ; Thu, 30 Sep 2004 13:47:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CD4zy-0004GE-SY for v6ops-data@psg.com; Thu, 30 Sep 2004 17:45:46 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CD4zo-0004FA-1A for v6ops@ops.ietf.org; Thu, 30 Sep 2004 17:45:36 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i8UHjT4d014869; Thu, 30 Sep 2004 10:45:30 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i8UHjQJQ026118; Thu, 30 Sep 2004 19:45:27 +0200 (MEST) Message-ID: <415C465D.2040900@sun.com> Date: Thu, 30 Sep 2004 10:46:05 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement References: <415C3771.4020702@sun.com> <20040930170515.GJ32021@login.ecs.soton.ac.uk> In-Reply-To: <20040930170515.GJ32021@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > But the 3gpp (and probably? enterprise) zct solution would be simpler for > not needing to support NAT traversal or proto 41 issues? Yes, but the requirements should include measurable criteria for simplicity, which is hard to do. One would also need to keep in mind that some devices probably need to implement both the 3GPP-specific tunneling and the generic tunneling, and what would the resulting complexity be if those solutions are different compared to if it is the same solution. Finally, simplicity in operations is probably a lot more important than simplicity in implementation in hosts and routers. > It seems the 3gpp community would also like a simple solution available > quickly (i.e. yesterday :) and thus pontificating over a more complex > solution would probably only lead to the 3gpp people developing the simple > solution anyway, outside the IETF process? I think there are folks that just want the IETF to bless whatever they've already decided to build and ship; that clearly would satisfy the timeliness requirement. But that might very well be the wrong thing to do for the Internet and IPv6 as a whole. > I think NAT traversal is adding complexity. If there was a simple, standards > based way to do NAT traversal now, then emerging IPv6 tunnel brokers would Whoa - "standards based"? We are talking about developing standards so we can require that the standards already exist can we? > be using it. While TSP is nice, when it comes to implementing a tunnel > broker, this is the trickiest aspect to its design (dynamic IPv4 being another > tricky - though less so - aspect). NAT traversal is easy for pt-pt - watch the almost RFC for IPsec (which I use today). But in v6ops we seem to conflate NAT traversal with the short-cut paths of Teredo. The short-cut paths is hard (what the the IP over large clouds IETF WGs a while back). Combining short-cuts with NATs doesn't make short-cuts easier. > I appreciate minimising the number of solutions is desirable, is there any > deployment problem having both zct and zct++ solutions? Depends a lot of the details. For instance: Can the hosts automatically detect which one to use? Does the infrastructure need to support both? Can this be done without duplication i.e. reusing the same boxes? Can the training of the operational staff be reused? Ideally you'd want what I recently experienced upgrading from standard IPsec tunneling to IPsec-over-NAT tunneling: just get a new software version and it just works (and same thing applied to the other end of the tunnel); had to use snoop/tcpdump to indeed verify that it does something new :-) But I fear that the complexity of short-cuts makes it hard to accomplish this; pt-pt tunnels would be easy I think. So can we defer the requirement for short-cuts to zct version 3? Do vanilla pt-pt in version 1, NAT traversal in version 2, and short-cuts in 3? Erik From owner-v6ops@ops.ietf.org Thu Sep 30 14:43:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17689 for ; Thu, 30 Sep 2004 14:43:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CD5sc-000Bt8-Us for v6ops-data@psg.com; Thu, 30 Sep 2004 18:42:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CD5sR-000BsC-Jq for v6ops@ops.ietf.org; Thu, 30 Sep 2004 18:42:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8UIg0X18198; Thu, 30 Sep 2004 21:42:00 +0300 Date: Thu, 30 Sep 2004 21:41:59 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement In-Reply-To: <415C3771.4020702@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 30 Sep 2004, Erik Nordmark wrote: > Pekka Savola wrote: > > People who have commented on this seem to have reached (off-list) > > consensus that draft-nielsen should be revised to be more explicitly > > 3GPP -specific, the 'simple' mode should be removed from assisted > > tunneling requirements, and a new document, discussing the the more > > general 'zero-config' problem space (ISP/unmanaged, possibly > > enterprise) should be written. > > I don't understand what this would mean. > I don't think we want a 3GPP specific (simple) tunneling mechanism, > which is incapable to work across v4NATs, while the generic tunneling > mechanism (which can work across NATs) is prohibited from having a > simple mode i.e. a mode which doesn't require pre-registration. > > But when reading the paragraph above that seems to be what you are > saying :-( > > Did you intend to say something else? I was saying that with s/mechanism/requirements/ I.e., having requirements in separate documents, allowing them to be developed separately, does not mean that the solutions need to be different. Similarly, if all the requirements for different scenarios were in the same document, it wouldn't mean that one solution would have to fulfill all the requirements. > The other big picture thing I don't understand is this space is the > issue about handling IPv4 NATs. > > The 3GPP specific requirements do not require working across a NAT, > which makes sense. But I see this being used as an argument that 3GPP > needs a solution which is incapable of working across a NAT, which makes > no sense at all; if there is a solution which satisfies the 3GPP > requirements as stated, then whether that solution satisfies additional > requirements should be ok. Personally, I completely agree with you wrt. the solution. (Completely personal opinion below) The critical thing will be whether the IETF 'honors' the 3GPP deadlines for a [standards track] solution (November this year). As you write, doing so would be very counterproductive. On the other hand, it could be also considered practical and admitting the reality. However, as such ISATAP will already go for Experimental RFC, so there will exist some documentation to create interoperable implementations in any case. There doesn't seem to be any particular reason to move it to standards track just because of 3GPP. -- 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 Thu Sep 30 14:46:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17974 for ; Thu, 30 Sep 2004 14:46:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CD5vs-000CJs-W9 for v6ops-data@psg.com; Thu, 30 Sep 2004 18:45:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CD5vi-000CI5-2n for v6ops@ops.ietf.org; Thu, 30 Sep 2004 18:45:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i8UIjGU18314; Thu, 30 Sep 2004 21:45:18 +0300 Date: Thu, 30 Sep 2004 21:45:16 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement In-Reply-To: <20040930165248.GI32021@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 30 Sep 2004, Tim Chown wrote: > For enterprise, can we assume the zct is also within the enterprise? My > feeling is yes. So the scenario is very similar. > > For umanaged (=soho largely), the zct would not be within the soho network, > rather from a host in the soho network to some external service. This > probably brings in NAT traversal, etc. In this case, perhaps we should > only be considering assisted tunnelling. ... > Thus (unless we have other broad scenarios?) we should push Karen's draft > for 3gpp and enterprise, and assisting tunnelling for unmanaged. This > could be documented in a reworked section 4 of Karen's draft? 'assisted tunneling' in the meaning 'registered' is IMHO not sufficient for unmanaged/soho case. The registration would be a heavy burden on the user, especially if we'd want to provide the users (or the vendors users are using) the capability to turn on v6 by default. 'non-registered assisted tunneling' is indeed the path of the generic zero-conf tunneling solution. 'enterprise internal' tunneling could likely use a similar solution as 3gpp, but the actual requirements might be different. -- 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 Thu Sep 30 15:39:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23176 for ; Thu, 30 Sep 2004 15:39:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CD6jV-000J8m-Ce for v6ops-data@psg.com; Thu, 30 Sep 2004 19:36:53 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CD6jK-000J7g-Mb for v6ops@ops.ietf.org; Thu, 30 Sep 2004 19:36:42 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i8UJacil005517; Thu, 30 Sep 2004 13:36:39 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i8UJaaJQ002793; Thu, 30 Sep 2004 21:36:37 +0200 (MEST) Message-ID: <415C606B.1040901@sun.com> Date: Thu, 30 Sep 2004 12:37:15 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > I was saying that with s/mechanism/requirements/ > > I.e., having requirements in separate documents, allowing them to be > developed separately, does not mean that the solutions need to be > different. Similarly, if all the requirements for different scenarios > were in the same document, it wouldn't mean that one solution would > have to fulfill all the requirements. But you were excluding the "simple" from the assisted tunneling requirements, and I don't understand why. If this is all about allowing different communities needing to express their requirements in a separate document, then don't exclude things from the documents. > (Completely personal opinion below) > The critical thing will be whether the IETF 'honors' the 3GPP > deadlines for a [standards track] solution (November this year). As > you write, doing so would be very counterproductive. On the other > hand, it could be also considered practical and admitting the reality. > However, as such ISATAP will already go for Experimental RFC, so there > will exist some documentation to create interoperable implementations > in any case. There doesn't seem to be any particular reason to move > it to standards track just because of 3GPP. If the purpose of the 3GPP requirements is solely to convince the IETF that they will use ISATAP (which they might have already decided), why are we wasting time on a 3GPP requirements document? A requirements document makes sense when multiple answers are acceptable, but you seem to be saying that only one answer would be acceptable. I don't have a problem with an experimental RFC describing ISATAP as currently implemented, and perhaps a separate document describing its limitations. Erik From owner-v6ops@ops.ietf.org Thu Sep 30 19:42:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14218 for ; Thu, 30 Sep 2004 19:42:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDAXI-000O3d-QF for v6ops-data@psg.com; Thu, 30 Sep 2004 23:40:32 +0000 Received: from [66.218.79.71] (helo=web80501.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CDAX0-000Nzk-5j for v6ops@ops.ietf.org; Thu, 30 Sep 2004 23:40:14 +0000 Message-ID: <20040930234013.13408.qmail@web80501.mail.yahoo.com> Received: from [63.197.18.101] by web80501.mail.yahoo.com via HTTP; Thu, 30 Sep 2004 16:40:13 PDT Date: Thu, 30 Sep 2004 16:40:13 -0700 (PDT) From: Fred Templin Subject: Re: Going forward with zero-config tunneling requirement To: Erik Nordmark , Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: <415C606B.1040901@sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1976068851-1096587613=:12072" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1976068851-1096587613=:12072 Content-Type: text/plain; charset=us-ascii Erik, Erik Nordmark wrote: > If the purpose of the 3GPP requirements is solely to convince the IETF > that they will use ISATAP (which they might have already decided), why > are we wasting time on a 3GPP requirements document? > A requirements document makes sense when multiple answers are > acceptable, but you seem to be saying that only one answer would be > acceptable. I did my best to present an analysis of various encapsulation alternatives (including ISATAP) in Section 10 of the IPvLX draft; see: http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt http://ipvlx.net Missing from the analysis is the fact that end nodes that are somehow unable to do IPvLX (or Teredo) can use ISATAP to connect to a first-hop IPv6 router, but I wonder whether users with multi-access capabilities would be willing to settle for that? > I don't have a problem with an experimental RFC describing ISATAP as > currently implemented, There are still some unanswered questions about ISATAP (including the above) so I guess that would suggest experimental. > and perhaps a separate document describing its limitations. IPvLX already touches on some of ISATAP's limitations and proposes an alternative. So, what do we want to do as a working group: start talking about IPvLX, or go on pretending that it doesn't exist? Thanks - Fred osprey67@yahoo.com --0-1976068851-1096587613=:12072 Content-Type: text/html; charset=us-ascii
Erik,
 
Erik Nordmark <erik.nordmark@sun.com> wrote:
 
> If the purpose of the 3GPP requirements is solely to convince the IETF
> that they will use ISATAP (which they might have already decided), why
> are we wasting time on a 3GPP requirements document?
> A requirements document makes sense when multiple answers are
> acceptable, but you seem to be saying that only one answer would be
> acceptable.
I did my best to present an analysis of various encapsulation alternatives
(including ISATAP) in Section 10 of the IPvLX draft; see:
 
 
Missing from the analysis is the fact that end nodes that are somehow
unable to do IPvLX (or Teredo) can use ISATAP to connect to a first-hop
IPv6 router, but I wonder whether users with multi-access capabilities
would be willing to settle for that?
 
> I don't have a problem with an experimental RFC describing ISATAP as
> currently implemented,
 
There are still some unanswered questions about ISATAP (including
the above) so I guess that would suggest experimental.
 
> and perhaps a separate document describing its limitations.
IPvLX already touches on some of ISATAP's limitations and proposes
an alternative. So, what do we want to do as a working group: start
talking about IPvLX, or go on pretending that it doesn't exist?
 
Thanks - Fred
--0-1976068851-1096587613=:12072--