Indeed, the use of this mechanism, to support a ds-lite tunnel initiated from a handset, is rather puzzling. How will the operator know which handset supports ds-lite, and what should happen if one doesn't?
Regards, Wojtek. On 14 October 2010 15:11, Maglione Roberta < [email protected]> wrote: > Dear Med, > Thanks for your reply and clarifications. > I was just trying to get the bigger picture about the applicability > scenario for this mechanism. I've understood now that your target are mobile > networks not fixed broadband customers, I believe it would be useful to add > this clarification in the document. > > The reason why I initially didn't think about mobile hosts was because I > thought that mobile use case can be addressed by the Gateway Initiated > Dual-Stack Lite approach (draft-ietf-softwire-gateway-init-ds-lite) where > the tunnel is established by the gateway, that would probably already > support DHCPv6, and not directly from the end hosts. > > Thanks > Regards, > Roberta > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] > Sent: giovedì 14 ottobre 2010 14.18 > To: Maglione Roberta; [email protected] > Cc: Ullio Mario; BINET David NCPI/NAD/TIP > Subject: RE: [Softwires] TR: I-D Action:draft-lee-6man-ra-dslite-00.txt > > Dear Roberta, > > Apologies for the delay to answer this e-mail. > > The deployment scenarios we have in mind are the same as for the DNS RA > option: > http://tools.ietf.org/html/draft-ietf-6man-dns-options-bis-08#section-1.1. > This RA option is meant to provide an default IPv6 route for IPv4-in-IPv6 > traffic when Ds-Lite is used. > > In some networks such as mobile ones, dhcp is not largely deployed. For SPs > who want to deploy CGN DS-Lite in mobile network, a means to convey the CGN > reachability information is required. RA is a candidate. > > For hosts which do not embed a dhcpv6 client (e.g., OSx), IPv4 connectivity > services cannot be delivered if the reachability information of the DS-Lite > AFTR is not provisioned to the host. > > We edited this document to challenge this idea and to assess whether it is > a bad or good idea. > > Cheers, > Med > > > -----Message d'origine----- > De : Maglione Roberta [mailto:[email protected]] > Envoyé : jeudi 7 octobre 2010 12:22 > À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email protected]; [email protected] > Cc : Ullio Mario > Objet : 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: [email protected] [mailto:[email protected]] On > Behalf Of [email protected] > Sent: martedì 28 settembre 2010 13.53 > To: [email protected]; [email protected] > 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 : [email protected] [mailto:[email protected]] > De la part de [email protected] > Envoyé : mardi 28 septembre 2010 08:00 > À : [email protected] > 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 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. > > > ********************************* > 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 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. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
