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: mohamed.boucad...@orange-ftgroup.com [mailto:mohamed.boucad...@orange-ftgroup.com] Sent: giovedì 14 ottobre 2010 14.18 To: Maglione Roberta; ipv6@ietf.org 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:roberta.magli...@telecomitalia.it] Envoyé : jeudi 7 octobre 2010 12:22 À : BOUCADAIR Mohamed NCPI/NAD/TIP; softwi...@ietf.org; ipv6@ietf.org 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: 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: softwi...@ietf.org; ipv6@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 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------