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

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

6204bis is a CE router requirements document. Not an operator
requirements document. 

RFC 6177 provides guidance regarding assignment of IPv6 prefixes to end
sites. Since this RFC already exists, and was recently published, I see
no need to try to write it again at this time.

Barbara

 

From: Ray Hunter [mailto:[e-mail]] 
Sent: Saturday, January 07, 2012 7:44 AM
To: STARK, BARBARA H
Cc: Wuyts Carl; Ole Troan; [e-mail]
Subject: Re: Re: [v6ops] Fwd: I-D Action:
draft-ietf-v6ops-6204bis-05.txt

 

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