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

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

By actively engaging in the creation of RFC 6204 and 6204bis, the
operator community engaged in this effort has effectively said that:

1. Operators who expect 6204(bis)-compliant CE routers to work with
their IPv6 access networks won't do things in their IPv6 access networks
that will cause these CE routers not to work. Operators who do not
expect these CE routers to work in their access networks may well do
things that cause these CE routers not to work in their access networks.
It is absolutely true that a 6204(bis)-compliant CE router cannot be
expected to work in an environment where it is not expected to work.

2. Operators who expect 6204(bis)-compliant CE routers to establish a
native IPv6 connection with their access networks will send RA. That RA
may or may not have a SLAAC ("A") prefix. This includes operators who do
PPP. See BBF TR-187
http://www.broadband-forum.org/technical/download/TR-187.pdf. [Things
may change in the future, but that change will have to be coordinated.]

3. Operators who expect 6204(bis)-compliant CE routers to establish a
native IPv6 connection with their IPv6 access networks will have a
DHCPv6 server that provides IA_PD and DNS. It may or may not supply
IA_NA or other config info.

 

The above operator expectations are implicit in RFC 6204(bis).

 

The requirements tell the CE router that

a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you
aren't expected to be able to establish an IPv6 connection with this
access network.

b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A"
prefix, that's ok. Clearly, the access network doesn't expect you to do
SLAAC if it doesn't send an "A" prefix. If it does send an "A" prefix,
then it does expect you to do SLAAC.

c) It's OK to always ask for IA_NA. But if M=1, then you MUST ask for
IA_NA. If you get an IA_NA offer, take it. If you don't get one, that's
ok. If the access network doesn't offer an IA_NA after you've asked for
one (or if M=0), then clearly it doesn't intend for you to have one.

d) Always ask for IA_PD. If you don't get IA_PD, then you aren't
expected to be able to establish IPv6 connectivity for your LAN. This
access network has no intention of supplying your LAN with IPv6
connectivity. 

e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then
take a single address from a /64, and associate it with an interface
(not the WAN interface) where you can use the address for
sending/receiving traffic to/from the LAN/WAN. IMO, the entire rest of
the /64 should always be available for use in the LAN. The "unnumbered"
model should never lock up an entire prefix. But we don't say that
anywhere. So I guess operators can't expect this to be the case. I
wouldn't be opposed to either stating that the unnumbered model might
lock up a /64 prefix, or requiring that it not lock up a /64 prefix. But
how to not lock up a prefix (if that's required) should be up to the CE
router vendor to implement.

 

It's important to understand that if an operator wants these CE routers
to work with their access network, then the operator won't do things
that will cause the device not to work. If an operator doesn't want the
CE router to work with their access network, then you shouldn't expect
to be able to create requirements that will allow the device to work.
Operators should expect CE routers to request IA_NA, independent of what
the operator puts in the RA (M bits, "A" flags). I agree that it's not a
good idea for the operator to support both SLAAC and IA_NA. And
operators know this. Contrary to popular belief, we aren't clueless.
While these requirements do not preclude stupidity in access network
design, operators are working hard (and together) to avoid stupid access
network design. And we're working with the CE community to try to make
sure that we express (reasonable) expectations for devices to work with
the access networks we design. Again, you're absolutely correct that the
expectations we've expressed are not intended to ensure that the devices
work on access networks of operators that have not been engaged in
creation of 6204(bis). But I can only assume that such operators have no
interest in such interoperability. Otherwise, they would be here.

Barbara

 

 

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

 

Well, seems like my comments are being taken the "wrong" way.

 

To come back on Barbara's comments:

""

<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).

[Carl] I agree 

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.

[Carl] I agree

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.

[Carl But I do not agree on this one. You want a "user configuration"
that either does SLAAC, DHCP_IA_NA or unnumbered.  In your opinion, this
must be done from a single configuration (no end-user interference, so
from "factory defaults").  So, the CPE must either able to "sense" the
configuration or just request all of the possible things ??  Sorry, but
not a good idea.  So, how must the CPE "sense" this and request the
appropriate configuration ?  Listen to RA ?  Fine, although you would
run into problems when, on a certain link (just say e.g. PPP), nothing
would be received, what would you do with that ?  No RA received, so ask
IA_NA ?  Fine again, but what if the DHCPv6 server does not provide
anything ?  Then you'd swap to "unnumbered" ?  What interface are you
going to use to put an address from ia_pd onto ?  Play "safe" and put it
on Lan interface (just to avoid issues if ia_pd = 64) ?

This maybe sounds ok for you, but in fact it's not.  Suppose the CPE has
been configured with all of the above, you might end with both putting
an address from ia_pd on top of an interface (no matter lan or virtual),
which is ok for me, but what if you end up in a situation, where the
DHCPv6 server does not return anything unless you ask for a specific set
of DHCPv6 options and if not, no info would be sent ?  In that case,
you're CPE ends up with ... no configuration at all, only link local
addresses.  What if your access network would support SLAAC, so you get
a prefix on the WAN intf trough SLAAC, but at the same time, you're also
asking IA_NA, so might get that one too + you put a prefix from ia_pa
too ?  It can still work, but not sure this would be the best idea
though.

So no matter how much more things you're adding for the CPE, you will
never have a 100% coverage.

 

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.

""

And on the one of "virtual intfs":

I can of course only agree that CPE vendors are perfectly capable of
deciding for the appropriate intf to put an address from ia_pa on top
off, however, if your req in RFC6204 uses "virtual interface" then  I'd
say your req can never be met in case of ia_pd length = 64.  If you want
to keep using this exact phrasing, then it is wrong.  So, if you know
state it does not matter what terminology is being used, then I'm
wondering why RFcs keep bothering to use lan, wan virtual, ... ???

 

On the comments from Ray on usage of /64 ia_pd length:

I can only say it is allowed.  I don't say it is a good idea, I don't
say we recommend it, but it's being used in the real world, so we're
facing it from day to day (again, it's residential market, and we have
to cope with those too, as after all, it is valid to use /64).  And
although you might consider this to be a "corner case", which I don't
think is really the case, then I would imagine it should still be
possible to use the RFC, no ?  If not, a statement must be added to the
RFC that this is only to be applied if your CPE is using ia_pd lengths
of < 64, which goes in against the basic IPv6 RFCs I'd say.

 

Regs

Carl

 

 

 

 

From: Ray Hunter [mailto:[e-mail]] 
Sent: zaterdag 7 januari 2012 13:44
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