Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

["STARK, BARBARA H" <[e-mail]>]

> > if the network only offers addresses via DHCP, how does the network
> trigger the CPE to ask for an IA_NA?
> > 6204 solution is to require the device to always ask.
> > [Carl]Just configuration, nothing more, nothing less.  If you want
> > ia_na, ask ia_na, if you don't, don't ask, no need to enforce this.
> What if you enforce ia_na and the server doesn't answer anyway ?
> Nothing accomplished.  What if you ask ia_na and the server is
> configured as such to not hand-out anything if ia_na is requested
(full
> match of requested options, if not match fully: nak) Keep it simple,
> it's usually the best.  If customer wants ia_na, configure the device
> as such, don't expect the CPE to do these things "auto-magically"
> 
> this isn't up to the customer. it is a choice by the access network.
> and I don't think the "here is a fax from your ISP, just type in these
> parameters" scheme is the best we can do. ;-)
> 
> [Carl] True, but there will be no "fax" from the ISP to the customer
> either to ask to switch something in configuration off either if it
> wouldn't work.  Anyway, I'm always flexible, so I say make it a SHOULD
> iso MUST, meaning "you should ask it unless you have a good reason not
> to do so", no ??

<bhs> The current requirement means that the customer doesn't have to
know anything about the access network (SLAAC or DHCPv6 IA_NA or
unnumbered). When we created 6204, one of the core goals was to identify
requirements that would allow a customer to plug the CE router in and
not have to know what address assignment mechanism the access network
used. Changing WPD-5 from MUST to SHOULD would completely demolish that
goal. If someone doesn't want to design their CE router per 6204, then
there's absolutely nothing that says they have to. It's not a
"standard". But if someone wants to build a router that can come up
without user configuration when connected to an access network that does
either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE
router must do. If someone wants a separate RFC for CE routers intended
for a different environment, then that's fine, too. But 6204 is for the
CE router intended to work in the environment specified in 6204.

As for the virtual interface comment -- my recollection of that was that
CE router designers wanted language that would basically let them put
that "unnumbered model" address wherever made sense for their box: LAN
interface, internal interface, logical interface, whatever. No need to
be specific, and leave it up to them. It just isn't the WAN interface
(because there's an RFC that says that's prohibited). From my
perspective, the CE router is a black box. If the access network
provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to
pick an address from a /64 of the IA_PD and be able to use that address
for sending/receiving traffic to/from the LAN/WAN (while making the
entire rest of that very same /64 available to the LAN for SLAAC). I
think that the new proposals (in the last few emails on this thread) to
split cases around when to put the address on a LAN interface and when
to put it on an internal interface based on = or > /64 in IA_PD go in
exactly the wrong direction. My experience has been that CE router
vendors are perfectly capable of determining the interface that makes
sense for their box. Realistically, the tests run at UNH-IOL wouldn't
check to see what interface the address is on. Because the specific
interface is not externally verifiable. The tests would check for (a) is
the device able to send/receive traffic to/from all ports (assuming LAN
isn't configured for multiple segments) using an address from the IA_PD,
and (b) does it also advertise the rest of that same /64 for use on the
LAN (SLAAC), and (c) do things just work after all this.</bhs>
Barbara