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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
