Re: [Softwires] TR: I-D Action:draft-lee-6man-ra-dslite-00.txt
Hello Med, I have a question about the deployment scenario you have in mind for this draft. In the document you say: A service provider may want to deploy DS-lite without using DHCP., but it is not completely clear to me what is the SLAAC only scenario you are referring to. I'm thinking about a DSL/Broadband access scenario where I have a residential gateway (RG) acting as B4 element, a BNAS terminating the IPv6 session and an additional device acting as AFTR element terminating the tunnel. In this case the RG can potentially get 2 IPv6 prefixes: - one to number to p2p WAN link, if the so-called, numbered model for the WAN link is used. This can be achieved either by using DHCPv6 or by using SLAAC; (if the unnumbered model is used this prefix is not present) - a second IPv6 prefix to number the devices in the home-network, behind the RG. This prefix is obtained by the RG via DHCPv6-PD and this is always required. My point is: if the RG is already running DHCPv6-PD in order to get a prefix for the home network, why cannot be enough to have ATFR tunnel name and address carried into DHCPv6 options? Thanks and best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: martedì 28 settembre 2010 13.53 To: softwires@ietf.org; i...@ietf.org Subject: [Softwires] TR: I-D Action:draft-lee-6man-ra-dslite-00.txt Dear all, FYI, we have submitted this new I-D. Comments, critiques, suggestions and questions are more than welcome. As mentioned in the draft, the provisioning of the AFTR is a very sensitive for the delivery of the IPv4 connectivity when DS-Lite is enabled. Any failure to provision such information means the failure for the delivery of IPv4 services. Furthermore, the availability of the IPv4 connectivity services does not depend on the availability of DHCPv6 or RADIUS servers. The draft includes in the appendix a use case for further discussion: distribute DS-Lite serviced customers among a set of deployed AFTRs. Provisioning the AFTR with an RA option simplifies this task and removes a constraint on DHCPv6 servers (no need to know where the customer is connected from). Off-line tools can be used instead for tuning the content of the information to be conveyed in an RA option. This use case has been included in the I-D to discuss whether it is a valid use case or not. We will move this use case to the core text if it is believed to be a valid scenario. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : mardi 28 septembre 2010 08:00 À : i-d-annou...@ietf.org Objet : I-D Action:draft-lee-6man-ra-dslite-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 RA Option for DS-Lite AFTR Element Author(s) : Y. Lee, M. Boucadair Filename: draft-lee-6man-ra-dslite-00.txt Pages : 8 Date: 2010-09-27 This document specifies a new optional extension to IPv6 Router Advertisement to allow IPv6 routers to advertise DS-Lite AFTR addresses to IPv6 hosts. The provisioning of the AFTR information is crucial to access IPv4 connectivity services in a DS-Lite context. Means to ensure reliable delivery of this information to connecting hosts is a must. Furthermore, this RA option can be used as a means to distribute DS- Lite serviced customers among a set of deployed AFTRs without requiring a central knowledge of the underlying topology and deployed AFTRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-6man-ra-dslite-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for
[Softwires] comments on draft-despres-softwire-6a44-00
Hi, Thanks for your work on this issue. I have some comments: 1. From 6a44 address format, the 6a44 client can only act as a IPv6 host but not IPv6 node which could attach to a IPv6 LAN. I think this is different from draft-lee-softwire-6rd-udp. 2. For host to host 6a44 communication, I think there is assumption that only one-layer NAT deployed between 6a44 hosts and 6a44 servers. 3. There is no text in the draft regarding to 6a44 server address provisioning. Since 6a44 servers are stateless, could anycast addresses be used? If there are some methods for this provisioning, 6a44 server would no need to use well-known UDP ports. 4. The draft presents 2 restrictions applying for 6a44 deployment in terms of MTU issue: o 6a44 ISP networks must have internal IPv4 MTUs of at least 1308 octets (which is easy to ensure). * 6a44 hosts must limit to 1280 octets IPv6 packets they transmit to destinations that are not neighbors on their own links. This behavior is already the normal one as long as no other IPv6 path MTU has been reliably discovered. o 6a44 Server functions refuse packets received from their IPv6 pseudo interfaces if their sizes exceed 1280 octets, with ICMPv6 Packet Too Big messages returned to sources as required by [RFC2460].) I assume the must appearing in the first bullet would have been MUST. I don't know the second bullet is MUST/SHOULD/MAY or anything else. Personally, MUST might be too restrictive for the second bullet. (My Provider deploys NATs in the residential area I live, for some apartments, there might be another NAT, itcould be easy to see 2-layer NATs for me;-) Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] comments on draft-despres-softwire-6a44-00
Thanks Washam for your detailed comments. Personal reaction below. Le 7 oct. 2010 à 13:46, Washam Fan a écrit : Hi, Thanks for your work on this issue. I have some comments: 1. From 6a44 address format, the 6a44 client can only act as a IPv6 host but not IPv6 node which could attach to a IPv6 LAN. I think this is different from draft-lee-softwire-6rd-udp. Yes. But 6rd-udp had such limitations on prefix lengths that it would have had to be modified. Private discussions led to only envisaged it, in practice, with a stateful NAT66 in the 6rd-udp client. If a NAT66 in a customer site is accepted, 6a44 can be used to provide its external address. 2. For host to host 6a44 communication, I think there is assumption that only one-layer NAT deployed between 6a44 hosts and 6a44 servers. Yes. There must be only a *LAN* between 6a44 hosts and CPEs (Fig. 1) 3. There is no text in the draft regarding to 6a44 server address provisioning. Good point. The information exists, but only indirectly (which is insufficient). The IANA section says: For 6a44 to be used, both its IPv4 well-known address B and its well-known port W need to be assigned by IANA. We could for example add in a next version a bullet in section 4 to say: B is the well-known IPv4 anycast address of the 6a44 Server function. Since 6a44 servers are stateless, could anycast addresses be used? If there are some methods for this provisioning, 6a44 server would no need to use well-known UDP ports. B is indeed an anycast address, as shown by: The 6a44 server function can be replicated in any number of routers, known as 6a44 Relays. The added bullet above, which better defines B, would make it clearer. 4. The draft presents 2 restrictions applying for 6a44 deployment in terms of MTU issue: o 6a44 ISP networks must have internal IPv4 MTUs of at least 1308 octets (which is easy to ensure). * 6a44 hosts must limit to 1280 octets IPv6 packets they transmit to destinations that are not neighbors on their own links. This behavior is already the normal one as long as no other IPv6 path MTU has been reliably discovered. o 6a44 Server functions refuse packets received from their IPv6 pseudo interfaces if their sizes exceed 1280 octets, with ICMPv6 Packet Too Big messages returned to sources as required by [RFC2460].) I assume the must appearing in the first bullet would have been MUST. Yes. It can be clarified in the next version. I don't know the second bullet is MUST/SHOULD/MAY or anything else. Personally, MUST might be too restrictive for the second bullet. This point isn't 100% clear, I agree. The text can be improved. (Yet, as long as PMTU discovery isn't considered reliable, the suggested course of action is the only one that preserves connectivity, which IMHO is a MUST.) (My Provider deploys NATs in the residential area I live, for some apartments, there might be another NAT, itcould be easy to see 2-layer NATs for me;-) Your provider is in the second case of Figure 1. To support 6a44, it MUST therefore have a 6a44 Server function next to its NAT function, at entrance of each residential area. If it can't, 6a44 isn't a solution for its network. No simple solution seems to exist in this case, if the IPv6 traffic between hosts of an apartment remains within the apartment (which is considered a MUST for a deployment without customers having bad surprises). Regards, RD PS: I added the two co-authors as cc destinations. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
Le 7 oct. 2010 à 02:56, Yiu L. Lee a écrit : Hi Fred, This is an interesting idea, but I will argue this is as complex as L2TP softwire. When Brian, Remi and I discussed, we would like to have a simple and cost effective technology that could be deployed by SP w/o upgrading the CPE. Indeed. We need some reliable and easily deployable solutions for IPv6 use to become widespread, including in hosts behind legacy CPEs. Whether some more complex and more powerful models can be designed next is an open issue. IMHO, it MUST NOT delay in any way adoption of the simple scheme. RD This double tunneling tech seems scary. Thanks, Yiu On 10/6/10 7:21 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Brian, -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, October 06, 2010 3:10 PM To: Ole Troan Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification On 2010-10-06 19:57, Ole Troan wrote: Brian, Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has just been posted (http://tools.ietf.org/html/draft-despres-softwire-6a44-00). It describes a solution for ISPs to offer native IPv6 across IPv4-only CPEs (NAT44 CPEs). It results from convergence discussion between authors of draft-carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00, taking into account comments made by authors of draft-lee-softwire-6rd-udp-01, and those made other Softwire WG participants since IETF 78. It is submitted to become, after discussion in the WG, a Softwire I-D. By the way, we do discuss in the draft why it's a useful alternative to both tunnel brokers (such as Hexago and SixXs) or Teredo. We don't explicitly discuss why we think it's also a useful alternative to an L2TP solution, but the arguments are, I think, similar to those for the tunnel brokers (apart from our hobbyist comment). perhaps you could also add some deployment considerations with regards to host tunneling versus network tunneling? OK, if there is enough interest to continue this work. Of course, in the context of legacy CPE, there is no alternative to host tunnels. I agree that the tunnel endpoint device in the end user network needs to configure the 6a44 tunnel interface as a host interface, but if the device also configures another tunnel over *that* then the inner tunnel could be used as a router interface. If you can bear with me for a moment (*), consider the 6a44 tunnel as an underlying interface over which the tunnel endpoint device configures an IRON tunnel. Yes, that would make for nested encapsulations - in particular, the nesting would be IPv6-in-IPv6-in-UDP-in-IPv4. But, the inner tunnel could be used as a router interface to service a PI IPv6 prefix. This would work even if the inner tunnel was configured over multiple underlying 6a44 tunnels - one each for each ISP the end user network connects to. (*) Of course, the sticking point once again is the pesky tunnel MTU issue. 6a44 appears to be punting on MTU yet again and setting a static 1280 MTU. That means that there is not enough available MTU to configure another tunnel over the 6a44 tunnel without fragmentation. If 6a44 is already implementing a control message protocol as per the I-D, however, it could also add a 6a44 Packet Too Big control message and use the IRON/SEAL method for reporting fragmentation as a means for supporting path MTU discovery. If you'd like a more detailed discussion of this idea, let me know. Thanks - Fred fred.l.temp...@boeing.com (Except for the idea in draft-lee-softwire-6rd-udp of a tiny relay plugged into the customer LAN.) Brian ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ v4tov6transition mailing list v4tov6transit...@ietf.org https://www.ietf.org/mailman/listinfo/v4tov6transition ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
This is an interesting idea, but I will argue this is as complex as L2TP softwire. When Brian, Remi and I discussed, we would like to have a simple and cost effective technology that could be deployed by SP w/o upgrading the CPE. Indeed. We need some reliable and easily deployable solutions for IPv6 use to become widespread, including in hosts behind legacy CPEs. why? my personal experience with host tunneling hasn't been great (ISATAP, Teredo, 6to4, configured, L2TP). and do ISPs really have an interest in supporting individual hosts? and be exposed to all of their peculiarities? it appears to me that we are filling in every possible square in the solution matrix. just because it is possible doesn't mean that it is useful or deployable... cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
Le 7 oct. 2010 à 15:45, Ole Troan a écrit : This is an interesting idea, but I will argue this is as complex as L2TP softwire. When Brian, Remi and I discussed, we would like to have a simple and cost effective technology that could be deployed by SP w/o upgrading the CPE. Indeed. We need some reliable and easily deployable solutions for IPv6 use to become widespread, including in hosts behind legacy CPEs. why? my personal experience with host tunneling hasn't been great (ISATAP, Teredo, 6to4, configured, L2TP). That is the whole point of proposing a really SIMPLE solution to solve a real problem. and do ISPs really have an interest in supporting individual hosts? and be exposed to all of their peculiarities? ISPs that aren't concerned with what their customer would like to have will eventually face competition. A key point is that supporting 6a44 is very inexpensive compared to other supports they have to envisage. Yet, as Yiu says, this still depends on which hosts will support 6a44. My personal hope is that we will soon see trials, including with mobile phones. it appears to me that we are filling in every possible square in the solution matrix. If you believe that IPv6 deployment is rapid enough, your lack of interest is understandable, but some have a different view. just because it is possible doesn't mean that it is useful or deployable... I never believed that!!! Yet a simple, reliable, and scalable solution is sometimes a good way to cut the gordian knot. 6rd was an example, and I personally believe that 6a44 has a great potential too. Cheers, RD cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs - Proposed 6a44 Specification
Le 7 oct. 2010 à 05:21, Olivier Vautrin a écrit : Hi all, very interesting draft. I think it would be worthwhile to elaborate a bit more in the draft why Teredo is not viable and thus an alternative is needed. In this draft, I see 2 issues described for Teredo: 1) clients sometimes believing that they have Teredo connectivity when in fact they don't Clients could have the same issue in 6a44 AFAIK. One problem of Teredo is that, between two valid Teredo addresses, it can break with some NAT behaviors. 6a44 avoids that. There is no mechanism in 6a44 to check the data path connectivity. For hosts that are on LANs behind NAT44-CPEs, there is no more IPv6 connectivity to be checked than between two any pair of hosts having native IPv6 addresses. Yet, there seems to be be something to add about customer sites having internally cascaded NATs, something like: NATs that are cascaded behind CPE NATs should disable the 6a44 well-nown port W for incoming packets. This can be done by a port mapping to an address that doesn't belong to the set of DHCP assigned addresses. I think the real issue here is lack of reliable teredo relay or lack of reliable data path (MTU issues). 2) Teredo server and relay being very remote Both issues can be fixed if ISPs deploy their own Teredo server/relay. Do you mean ALL ISPs? If yes, it isn't a practical solution. Besides, do you suggest that IPv6 sensor devices that need the incoming connectivity that IPv6 can restore would have to support Teredo? Which is basically what they will do with 6a44. The point of 6a44 is that each ISP can incrementally deploy the solution (like 6rd, or also the 4rd that both of us proposed ;-)) So, I don't really see the issues described in the paper as important enough to create another protocol. I do think there are other issues with Teredo: 1) Use of a WK prefix instead of an ISP prefix. This means the return path can be broken as with 6to4. 2) Most client Teredo implementation need a full cone NAT on the CPE. Most CPE use symmetric NAT. so a CPE upgrade could be needed. 3) Most OS still prefer IPv4 over Teredo. This means it does not increase the Ipv6 traffic. 4) On vista, it seems that traffic is sent to a Teredo tunnel only if another Ipv6@ is created (I didn't check this though). Source: http://yorickdowne.wordpress.com/2008/01/26/ipv6-at-home-part-1-overview-teredo/ It shouldn't be long to developer who knows 6to4 under Linux to implement 6a44. It's a new protocol, yes, but a very simple one to implement and to operate. Regards, RD /Olivier -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Tuesday, October 05, 2010 9:51 PM To: Softwires Cc: v4tov6transit...@ietf.org Subject: Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs - Proposed 6a44 Specification On 2010-10-05 22:26, Rémi Després wrote: Hi all, Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has just been posted (http://tools.ietf.org/html/draft-despres-softwire- 6a44-00). It describes a solution for ISPs to offer native IPv6 across IPv4- only CPEs (NAT44 CPEs). It results from convergence discussion between authors of draft- carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00, taking into account comments made by authors of draft-lee-softwire-6rd-udp-01, and those made other Softwire WG participants since IETF 78. It is submitted to become, after discussion in the WG, a Softwire I- D. By the way, we do discuss in the draft why it's a useful alternative to both tunnel brokers (such as Hexago and SixXs) or Teredo. We don't explicitly discuss why we think it's also a useful alternative to an L2TP solution, but the arguments are, I think, similar to those for the tunnel brokers (apart from our hobbyist comment). Brian ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6across NAT44 CPEs -Proposed 6a44 Specification
Hi Yiu, -Original Message- From: v4tov6transition-boun...@ietf.org [mailto:v4tov6transition-boun...@ietf.org] On Behalf Of Yiu L. Lee Sent: Wednesday, October 06, 2010 5:57 PM To: Templin, Fred L; Brian E Carpenter; Ole Troan Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [v4tov6transition] [Softwires] ISP support of Native IPv6across NAT44 CPEs -Proposed 6a44 Specification Hi Fred, This is an interesting idea, but I will argue this is as complex as L2TP softwire. When Brian, Remi and I discussed, we would like to have a simple and cost effective technology that could be deployed by SP w/o upgrading the CPE. This double tunneling tech seems scary. I used the double tunneling example as something that could be done and not necessarily something that should be done - it is not at all a requirement of IRON, and would not be as efficient as deploying IRON alone without also deploying 6a44 or the like. But, it might be worth noting that the hard-coded 1280 MTU precludes configuring other tunnels over 6a44 tunnels. AFAICT, if the ISPs want to let their customers set up native IPv6 networks behind unmodified IPv4 NATs the two choices are to 1) do nothing, and let outside agencies deploy the IRON service, or 2) deploy the IRON service themselves. This gets back to a point that needs to be bumped up a level in visibility. Some of these proposed approaches are strictly provider-aggregated, which may be good for the ISPs but maybe not so optimal for the customers. IRON provides the customers with a provider-independent routing and addressing service that can be carried over any ISP(s) the customers happens to procure their basic connectivity services from. About complexity comparisons, based on my limited knowledge of L2TP the IRON architectural principles don't have a parallel in the L2TP model. But, when it comes to control and data plane messaging, I can say with some confidence based on the code I am writing that IRON is much simpler. Thanks - Fred fred.l.templ...@boeing.com Thanks, Yiu On 10/6/10 7:21 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Brian, -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Wednesday, October 06, 2010 3:10 PM To: Ole Troan Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification On 2010-10-06 19:57, Ole Troan wrote: Brian, Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has just been posted (http://tools.ietf.org/html/draft-despres-softwire-6a44-00). It describes a solution for ISPs to offer native IPv6 across IPv4-only CPEs (NAT44 CPEs). It results from convergence discussion between authors of draft-carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00, taking into account comments made by authors of draft-lee-softwire-6rd-udp-01, and those made other Softwire WG participants since IETF 78. It is submitted to become, after discussion in the WG, a Softwire I-D. By the way, we do discuss in the draft why it's a useful alternative to both tunnel brokers (such as Hexago and SixXs) or Teredo. We don't explicitly discuss why we think it's also a useful alternative to an L2TP solution, but the arguments are, I think, similar to those for the tunnel brokers (apart from our hobbyist comment). perhaps you could also add some deployment considerations with regards to host tunneling versus network tunneling? OK, if there is enough interest to continue this work. Of course, in the context of legacy CPE, there is no alternative to host tunnels. I agree that the tunnel endpoint device in the end user network needs to configure the 6a44 tunnel interface as a host interface, but if the device also configures another tunnel over *that* then the inner tunnel could be used as a router interface. If you can bear with me for a moment (*), consider the 6a44 tunnel as an underlying interface over which the tunnel endpoint device configures an IRON tunnel. Yes, that would make for nested encapsulations - in particular, the nesting would be IPv6-in-IPv6-in-UDP-in-IPv4. But, the inner tunnel could be used as a router interface to service a PI IPv6 prefix. This would work even if the inner tunnel was configured over multiple underlying 6a44 tunnels - one each for each ISP the end user network connects to. (*) Of course, the sticking point once again is the pesky tunnel MTU issue. 6a44 appears to be punting on MTU yet again and setting a static 1280 MTU. That means that there is not enough available MTU to configure another tunnel over the 6a44 tunnel without fragmentation. If 6a44 is already implementing a control message protocol as per the I-D, however, it could also add a 6a44 Packet Too Big control
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
Remi, [...] ISPs that aren't concerned with what their customer would like to have will eventually face competition. we are in complete agreement of the end goal. it is just how we get there... A key point is that supporting 6a44 is very inexpensive compared to other supports they have to envisage. Yet, as Yiu says, this still depends on which hosts will support 6a44. My personal hope is that we will soon see trials, including with mobile phones. issues I have with host tunneling: - how to communicate with native IPv6 nodes on the same network? - how to communicate to another 6a44 host on a different link in the same home? - do you need non-congruent topology multi-homing policy? http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01 how do you distribute that policy when you don't have a on-link router? - a general unease that now every host is supposed to have a VPN connection? how do I configure my own firewall and other network border policy? how much would a new CPE cost the customer? 80USD? that's only 5 pints of beer (if bought in Norway.) I really liked the dongle idea by the way. perhaps with a L2TP LAC. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
I can't say how bad operators want to support IPv6 over legacy CPEs. If there is demand. Can somebody (except me :-) ) speak it out? Well, when we surveyed 31 ISPs for draft-ietf-v6ops-isp-scenarios, we found When asked which types of equipment are unable to support IPv6, the most common answer was CPE (10 mentions). That doesn't directly answer your question, but it suggests the size of the problem. Regards Brian Carpenter On 2010-10-08 02:53, Yiu L. Lee wrote: Hi Ole, I agree with you the host model isn't very attractive for average users. If IPv4 can get me to every site, why I want to install a software to bring me to the same set of sites over v6? 6rd is great tech, users don't need to do anything. The only drawback is users will have to change the CPE. For some operators, this may be a hurdle. I can't say how bad operators want to support IPv6 over legacy CPEs. If there is demand. Can somebody (except me :-) ) speak it out? Thanks, Yiu On 10/7/10 9:45 AM, Ole Troan otr...@employees.org wrote: This is an interesting idea, but I will argue this is as complex as L2TP softwire. When Brian, Remi and I discussed, we would like to have a simple and cost effective technology that could be deployed by SP w/o upgrading the CPE. Indeed. We need some reliable and easily deployable solutions for IPv6 use to become widespread, including in hosts behind legacy CPEs. why? my personal experience with host tunneling hasn't been great (ISATAP, Teredo, 6to4, configured, L2TP). and do ISPs really have an interest in supporting individual hosts? and be exposed to all of their peculiarities? it appears to me that we are filling in every possible square in the solution matrix. just because it is possible doesn't mean that it is useful or deployable... cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs - Proposed 6a44 Specification
Olivier, Rémi has mainly answered you. In particular, the operational problems caused by missing Teredo servers don't just harm the customers of the ISP concerned; like missing 6to4 relays, they also harm customers of *other* ISPs. 6a44 doesn't have this problem. I think it would be worthwhile to elaborate a bit more in the draft why Teredo is not viable and thus an alternative is needed. I believe that a separate draft on operational problems with Teredo would be useful (in v6ops, most likely). Personally, I'd rather keep the 6a44 draft more focussed. Regards Brian On 2010-10-07 16:21, Olivier Vautrin wrote: Hi all, very interesting draft. I think it would be worthwhile to elaborate a bit more in the draft why Teredo is not viable and thus an alternative is needed. In this draft, I see 2 issues described for Teredo: 1) clients sometimes believing that they have Teredo connectivity when in fact they don't Clients could have the same issue in 6a44 AFAIK. There is no mechanism in 6a44 to check the data path connectivity. I think the real issue here is lack of reliable teredo relay or lack of reliable data path (MTU issues). 2) Teredo server and relay being very remote Both issues can be fixed if ISPs deploy their own Teredo server/relay. Which is basically what they will do with 6a44. So, I don't really see the issues described in the paper as important enough to create another protocol. I do think there are other issues with Teredo: 1) Use of a WK prefix instead of an ISP prefix. This means the return path can be broken as with 6to4. 2) Most client Teredo implementation need a full cone NAT on the CPE. Most CPE use symmetric NAT. so a CPE upgrade could be needed. 3) Most OS still prefer IPv4 over Teredo. This means it does not increase the Ipv6 traffic. 4) On vista, it seems that traffic is sent to a Teredo tunnel only if another Ipv6@ is created (I didn't check this though). Source: http://yorickdowne.wordpress.com/2008/01/26/ipv6-at-home-part-1-overview-teredo/ /Olivier -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Tuesday, October 05, 2010 9:51 PM To: Softwires Cc: v4tov6transit...@ietf.org Subject: Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs - Proposed 6a44 Specification On 2010-10-05 22:26, Rémi Després wrote: Hi all, Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has just been posted (http://tools.ietf.org/html/draft-despres-softwire- 6a44-00). It describes a solution for ISPs to offer native IPv6 across IPv4- only CPEs (NAT44 CPEs). It results from convergence discussion between authors of draft- carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00, taking into account comments made by authors of draft-lee-softwire-6rd-udp-01, and those made other Softwire WG participants since IETF 78. It is submitted to become, after discussion in the WG, a Softwire I- D. By the way, we do discuss in the draft why it's a useful alternative to both tunnel brokers (such as Hexago and SixXs) or Teredo. We don't explicitly discuss why we think it's also a useful alternative to an L2TP solution, but the arguments are, I think, similar to those for the tunnel brokers (apart from our hobbyist comment). Brian ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs -Proposed 6a44 Specification
On Thu, Oct 7, 2010 at 5:07 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I can't say how bad operators want to support IPv6 over legacy CPEs. If there is demand. Can somebody (except me :-) ) speak it out? Well, when we surveyed 31 ISPs for draft-ietf-v6ops-isp-scenarios, we found When asked which types of equipment are unable to support IPv6, the most common answer was CPE (10 mentions). That doesn't directly answer your question, but it suggests the size of the problem. Brian is right. And when a customer asks for IPv6 features in end nodes, through any number channels (public, private, RFP, ...), the answers is frequently something like /dev/null . For instance, http://tinyurl.com/2f753c5 ... So, if you work for a vendors that makes CPE / UE, please consider turning IPv6 on in your product. Cameron ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 11:58 AM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org
Re: [Softwires] DHCPv6 AFTR name option is needed
Dear Tomek, Thank you for this clarification. Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference. To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned). With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR. Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context. Hope this clarifies our concern. Cheers, Med De : Tomasz Mrugalski [mailto:tomasz.mrugal...@gmail.com] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta roberta.magli...@telecomitalia.itmailto:roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.orgmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.orgmailto:softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Cc : softwires@ietf.orgmailto:softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand
