[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. message/external-body; name="draft-lee-6man-ra-dslite-00.url": Unrecognized ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] comments on draft-carpenter-softwire-sample-00
On 9/28/10 4:09 AM, Yiu L. Lee wrote: Hi Washam, Don't forget there are also Softwire Hub-and-Spoke (L2TPv2 based) and 6rd+. So far, we don't hear much response to support this work in the operator's community. I know of more than one L2TPv2 based softwire deployments active today. A new one is getting ready to go online soon as well (sorry, not my place to spill the beans on who). Given existing deployment of L2TP and TSP, I still find it hard to see why another stateful point-to-point tunnel is really necessary at this stage of the game. - Mark Regards, Yiu On 9/27/10 9:49 PM, WashamFan washam@huaweisymantec.com wrote: Hi, Please see inline. - Original Message - From: Brian E Carpenter brian.e.carpen...@gmail.com Date: Tuesday, September 28, 2010 4:17 am Subject: Re: [Softwires] comments on draft-carpenter-softwire-sample-00 To: WashamFan washam@huaweisymantec.com Cc: softwires@ietf.org Hi, On 2010-09-27 21:05, WashamFan wrote: Hi, It says, The SAMPLE server will act as an IPv6 router. In the simplest case, it will forward all IPv6 packets to a default route, except those whose destination address lies within the PSAMPLE prefix, which will be encapsulated and sent towards the host (CPE) and port indicated by the V4ADDR and PN values. I think it is not appropriate to assume NAT traversal without relay can be always successful. I don't understand your comment. If you have a NAT that you cannot traverse with UDP, you have many other problems, not just a lack of IPv6 connectivity. I misunderstood. I thought the text implies direct tunnels established instead of hairpinning via SAMPLE server when SAMPLE client to SAMPLE client communication occurs . Hairpinning might be always used for simplicity. Yes, that is the SAMPLE model. And it's a discussion for the community whether or not this is acceptable. I'd like to know the status of the draft, is the WG pursuing this work? There are three drafts aiming at the same problem, SAMPLE, draft-lee-softwire-6rd-udp, and draft-despres-softwire-6rdplus. Please hold your breath, there's hope of a joint proposal from several authors within a few days. Is it possible to combine all these efforts? I see 2 major difference between draft-carpenter-softwire-sample-00 and draft-lee-softwire-6rd-udp-02 at least: 1. According to the IPv6 address assignment, SAMPLE is to connect isolated IPv6 hosts but 6rd-udp is to connect both isolated IPv6 hosts and LANs. 2. They are different in terms of IPv6 address assignment procedure. SAMPLE uses ND but 6rd-udp might use RADIUS, let's say. Personally, I think it is meaningful to work on tunneling IPv6 traversing NAT, but I think we should justify the work by clarifying how bad Teredo did the job before we reinvent the wheel. THanks, washam 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] comments on draft-carpenter-softwire-sample-00
On 9/28/10 4:28 AM, Brian E Carpenter wrote: On 2010-09-28 15:09, Yiu L. Lee wrote: Hi Washam, Don't forget there are also Softwire Hub-and-Spoke (L2TPv2 based) and 6rd+. So far, we don't hear much response to support this work in the operator's community. One reason is that the smaller, more agile ISPs with problems in this area are simply figuring out how to deal with Teredo, e.g. with Tui boxes, http://www.braintrust.co.nz/tui/ Oh yeah, that one too. IMNSHO, cumbersome solutions like L2TPv2 will only appeal to telco-like operators. L2TP is often the NNI which allows a challenger ISP to setup service to subscribers where the telco-like incumbent owns the physical layer (in particular for remote locations where co-location might not be a reasonable option). So, it ends up in a lot of different types of ISPs, even those that do not have PPP anywhere else. The one place where it almost never ends up is at a DOCSIS cable operator, which is where I hear most of the resistance to its introduction. L2TP would and should lose a beauty contest with a brand new protocol created today (surely we would have learned something in 15 years!). However, on the concentrator side, virtually every SP vendor has an LNS offering, alongside open source options if you want to go that route. On the client side, it is in a number of RGs, pretty much every host OS, not to mention your iPhone, iPad, Android... It's everywhere. Why not just use it? PPP isn't *that* hard. - Mark Brian Regards, Yiu On 9/27/10 9:49 PM, WashamFan washam@huaweisymantec.com wrote: Hi, Please see inline. - Original Message - From: Brian E Carpenter brian.e.carpen...@gmail.com Date: Tuesday, September 28, 2010 4:17 am Subject: Re: [Softwires] comments on draft-carpenter-softwire-sample-00 To: WashamFan washam@huaweisymantec.com Cc: softwires@ietf.org Hi, On 2010-09-27 21:05, WashamFan wrote: Hi, It says, The SAMPLE server will act as an IPv6 router. In the simplest case, it will forward all IPv6 packets to a default route, except those whose destination address lies within the PSAMPLE prefix, which will be encapsulated and sent towards the host (CPE) and port indicated by the V4ADDR and PN values. I think it is not appropriate to assume NAT traversal without relay can be always successful. I don't understand your comment. If you have a NAT that you cannot traverse with UDP, you have many other problems, not just a lack of IPv6 connectivity. I misunderstood. I thought the text implies direct tunnels established instead of hairpinning via SAMPLE server when SAMPLE client to SAMPLE client communication occurs . Hairpinning might be always used for simplicity. Yes, that is the SAMPLE model. And it's a discussion for the community whether or not this is acceptable. I'd like to know the status of the draft, is the WG pursuing this work? There are three drafts aiming at the same problem, SAMPLE, draft-lee-softwire-6rd-udp, and draft-despres-softwire-6rdplus. Please hold your breath, there's hope of a joint proposal from several authors within a few days. Is it possible to combine all these efforts? I see 2 major difference between draft-carpenter-softwire-sample-00 and draft-lee-softwire-6rd-udp-02 at least: 1. According to the IPv6 address assignment, SAMPLE is to connect isolated IPv6 hosts but 6rd-udp is to connect both isolated IPv6 hosts and LANs. 2. They are different in terms of IPv6 address assignment procedure. SAMPLE uses ND but 6rd-udp might use RADIUS, let's say. Personally, I think it is meaningful to work on tunneling IPv6 traversing NAT, but I think we should justify the work by clarifying how bad Teredo did the job before we reinvent the wheel. THanks, washam 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] comments on draft-carpenter-softwire-sample-00
Hi Remi, Personally, I think it is very meaningful to address tunneling IPv6 over IPv4 with NAT traversal issue, especially in China. We have less IPv4 address space assigned at the first place, compared to the huge population, the address per person ratio is very low, I suspect some ISPs have already deployed some kind of NATs somewhere in their network. (As myself, I got 10/8 from my provider). In the other hand, we bought CPE outselves, the ISP can not control the CPES most of time, I am afraid. That is very different from that in Europe or America, I guess. My impression is, from my experience surfing the Internet, I would go thru one layer NAT (deployed by my provider in my residential building) and a 192.168 network (somewhere in the SP network) before I hit the Internet finally. When my ISP is going to provide IPv6 to me, let's say, 6rd as the first step, the existing complex network arch would hinder the classic 6rd deployed. I am looking forward to the new combined proposal. Thanks, washam - Original Message - From: Rémi Després remi.desp...@free.fr Date: Wednesday, September 29, 2010 1:03 am Subject: Re: [Softwires] comments on draft-carpenter-softwire-sample-00 To: WashamFan washam@huaweisymantec.com Cc: Brian E Carpenter brian.e.carpen...@gmail.com, softwires@ietf.org Hi Washam, As Brian suggested, it might be best to wait for the new proposal (we work together on it). It is intended to combine, improve, and complete, draft-carpenter-6man-sample and draft-despres-softwire-6rdplus. Traffic between two NAT44 sites is, as you suggested, always based on hairpinning (simpler and, even more important IMHO, resistant to all odd NAT behaviors). Its other distinctive property is that hosts behind the same NAT44 communicate directly within their site using their IPv6 addresses. Your comments will be most welcome when the draft is available. Regards, RD Le 28 sept. 2010 à 03:49, WashamFan a écrit : Hi, Please see inline. - Original Message - From: Brian E Carpenter brian.e.carpen...@gmail.com Date: Tuesday, September 28, 2010 4:17 am Subject: Re: [Softwires] comments on draft-carpenter-softwire-sample-00 To: WashamFan washam@huaweisymantec.com Cc: softwires@ietf.org Hi, On 2010-09-27 21:05, WashamFan wrote: Hi, It says, The SAMPLE server will act as an IPv6 router. In the simplest case, it will forward all IPv6 packets to a default route, except those whose destination address lies within the PSAMPLE prefix, which will be encapsulated and sent towards the host (CPE) and port indicated by the V4ADDR and PN values. I think it is not appropriate to assume NAT traversal without relay can be always successful. I don't understand your comment. If you have a NAT that you cannot traverse with UDP, you have many other problems, not just a lack of IPv6 connectivity. I misunderstood. I thought the text implies direct tunnels established instead of hairpinning via SAMPLE server when SAMPLE client to SAMPLE client communication occurs . Hairpinning might be always used for simplicity. Yes, that is the SAMPLE model. And it's a discussion for the community whether or not this is acceptable. I'd like to know the status of the draft, is the WG pursuing this work? There are three drafts aiming at the same problem, SAMPLE, draft-lee-softwire-6rd-udp, and draft-despres-softwire-6rdplus. Please hold your breath, there's hope of a joint proposal from several authors within a few days. Is it possible to combine all these efforts? I see 2 major difference between draft-carpenter-softwire-sample-00 and draft-lee-softwire-6rd-udp-02 at least: 1. According to the IPv6 address assignment, SAMPLE is to connect isolated IPv6 hosts but 6rd-udp is to connect both isolated IPv6 hosts and LANs. 2. They are different in terms of IPv6 address assignment procedure. SAMPLE uses ND but 6rd-udp might use RADIUS, let's say. Personally, I think it is meaningful to work on tunneling IPv6 traversing NAT, but I think we should justify the work by clarifying how bad Teredo did the job before we reinvent the wheel. THanks, washam 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
