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

[Ray Hunter <[e-mail]>]

Speaking as an end user of the Internet: and in the spirit of your 
comment on virtual interfaces, why should v6ops make life difficult for 
itself and get involved at all in corner cases where there is a conflict 
between what are essentially network operators' deployment decisions, 
and router vendors' engineering decisions? IMVVVVHO V6ops should not be 
defining technical workarounds for non-technical problems like the size 
of the PD assignment.

Various authorities have bent over backwards to ensure that IPv6 
addresses are globally plentiful and that they are "very much cheaper" 
than IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE 
for an IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range 
per household seems unnecessarily mean and potentially harmful to 
transparent end-to-end connectivity on the Internet, possibly forcing 
end users to deploy complex prefix splitting beyond /64 within their CPE 
router and thus breaking SLAAC, or perhaps even worse, deploying NAT66.

Perhaps the practical solution for 6204bis would be for v6ops to 
recommend that network operators delegate "sufficient addresses" to end 
user sites (as suggested earlier by Ole), and perhaps even going as far 
as recommending a minimum PD assignment of /60 or /56 for customers 
using 6204bis compliant equipment. The choice of /60 or /56 being based 
on the ability to potentially delegate reverse DNS, and to allow end 
users of the Internet to deploy flexible and reasonable local topologies 
e.g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 
CE router may have one or more network-layer LAN interfaces).

Regards,
RayH

STARK, BARBARA H wrote:
>>> 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 =r>  /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
>
>
>