Concerning the O flag with RDNSS, you're
absolutely right, the O bit could be set to 1 if other pertinent information
is available. We should modify it to say "O flag could be set to 0
if no other additional information than recursive DNS servers is available
by DHCPv6".
For the DAD graceful failure, do you
have any idea of what other address could be used? Maybe if 2 DHCPv6 ADVERTISE
were received from different servers, another REQUEST could be sent to
the second server. Otherwise I don't see how we could make the DAD failure
more graceful.
And last, concerning RS and DHCPv6 in
parallel, it looks like a good idea. The draft was designed with a provisioning
model very close to the current CableLabs specifications for IPv6 cable
modem provisioning, where both operations are done in sequence. Since this
is a CPE spec, nothing IMHO would prevent the two operations to be done
in parallel.
Jean-Francois Tremblay
Videotron
"Stark, Barbara"
<bs7652@att.com> Envoyé par : owner-v6ops@ops.ietf.org
RE: New Version Notification for draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00
Thanks for this draft. I think you present some interesting ideas, and
I
found the format to be very readable.
Several DSL providers are considering using an "unnumbered" model
on the
WAN interface. This means that the CPE Router will not be given a GUA
address through either SLAAC or DHCPv6. If the CPE Router isn't given an
address through SLAAC or DHCPv6, then it's expected to use an address
from the delegated prefix for any applications that need to communicate
with the WAN. This address would not be associated with the WAN
interface, but with some other interface (a LAN interface, an internal
physical or logical interface, a loopback interface, etc.). Any CPE
Router that expects to work on a random DSL provider's network would
need to be able to handle this scenario.
This is the only element of your draft that I saw that would actually be
incompatible with some DSL access networks.
There are some other differences, however, between your draft and the
design decisions that some DSL providers are making for their CPE
routers. Here are some that may interest you:
- because the CPE router is always expected to do a DHCPv6 message
sequence to get the PD, it's been suggested that the RS/RA and DHCPv6
message sequences can be started at the same time; in this case, the M
and O bits are ignored by the CPE Router and the DHCPv6 solicit always
includes the IA_NA and IA_PD options. If the RA includes prefixes for
SLAAC, the Router does SLAAC. If the DHCPv6 response includes an address
for IA_NA, then the Router uses that. (If both, then both, but hopefully
a provider's network won't do that). If neither, then the Router takes
an address from the PD prefix. This shortens the time to completion of
setup (parallel RS/RA and DHCPv6, instead of sequential) and allows the
CPE router logic to be simpler (the DHCPv6 messages are always the
same). The service provider has complete control over whether the DHCPv6
server does or doesn't provide a GUA in response to the IA_NA option. I
would be curious to know if a cable access network might react badly to
a CPE Router that did this. That is, if a consumer plugged such a Router
from a DSL provider (many of these routers have Ethernet WAN interfaces)
into a bridged cable modem, would there be a problem?
- if DAD fails, it may be a good idea to try a different address,
before giving up; vendors are encouraged to provide more graceful
handling of DAD failures, than terminating operation on the interface.
As an additional comment, I see that SHP-REQ5 requires the CPE Router to
set the O flag to 0 in its RA if it does RDNSS (RFC 5006) in that RA.
And SHP-REQ4 suggests that the CPE Router pass along additional options
that it got from WAN DHCPv6. Since the RDNSS option only provides DNS,
and the DHCPv6 message (from the WAN) might contain all sorts of other
information, I'm curious as to why you don't think the Router should let
LAN hosts know about the availability of additional options by setting
O
to 1.
Barbara
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Chris Donley
> Sent: Thursday, July 09, 2009 11:12 AM
> To: v6ops@ops.ietf.org
> Subject: FW: New Version Notification for draft-donley-ipv6-cpe-rtr-
> use-cases-and-reqs-00
>
> Hello,
>
> We just posted a new draft, "Use Cases and Requirements for an
IPv6
CPE
> Router," draft-donley-ipv6-cpe-rtr-use-cases-and-reqs. We would
> appreciate your feedback.
>
> Thanks,
> Chris
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> Sent: Thursday, July 02, 2009 3:28 PM
> To: Deepak Kharbanda
> Cc: Chris Donley; john_brzozowski@cable.comcast.com;
> yiu_lee@cable.comcast.com; jason.weil@cox.com;
> kirk.erichsen@twcable.com; william.howard@twcable.com;
> trembjfr@videotron.com
> Subject: New Version Notification for
> draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00
>
>
> A new version of I-D,
> draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00.txt has been
> successfuly
> submitted by Deepak Kharbanda and posted to the IETF repository.
>
> Filename:
draft-donley-ipv6-cpe-rtr-use-cases-and-reqs
> Revision:
00
> Title:
Use Cases and Requirements for an IPv6 CPE
Router
> Creation_date:
2009-07-02
> WG ID:
Independent Submission
> Number_of_pages: 24
>
> Abstract:
> This document captures use cases and associated requirements for an
> IPv6 Customer Premises Equipment (CPE) router. Specifically,
the
> current version of this document focuses on the provisioning of an
> IPv6 CPE router and the provisioning of IPv6 Home Devices attached
to
> it. It also addresses IPv6 traffic forwarding and IPv6 CPE Router
> security. This document also identifies areas for future
> consideration. These areas include prefix sub-delegation, IPv6
> multicast, transition and tunneling mechanisms, provisioning
> consistency between DHCPv4 and DHCPv6, and DNS support. This
> document does not address IPv4 use cases or requirements, as they
are
> widely understood; however, it is expected that IPv6 CPE Routers will
> also support IPv4.
>
>
>
>
> The IETF Secretariat.
>
>