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

[Fred Baker <[e-mail]>]

I'll add him to the list. However, frankly, it would b good to be having the discussions in the open as the draft is being finalized. It's a working group document.

On Jan 8, 2012, at 2:09 PM, Hemant Singh (shemant) wrote:

> Carl,
> 
> It would also be good to join the cpe router mailing list if you have so
> many comments on the document.   Please email [e-mail] and he will
> add you to the mailer.  All your questions have been closed in the
> design team mailer without changing any more text in the rfc6204bis
> document.  An SP doling out an IA_PD of /64 length does not make sense.
> The device is an IPv6 router and it is so common for a router to create
> a virtual interface to source packets from. 
> 
> Hemant
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of STARK, BARBARA H
> Sent: Friday, January 06, 2012 10:07 AM
> To: Wuyts Carl; Ole Troan
> Cc: [e-mail]
> Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt
> 
>>> 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
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops