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

[Wuyts Carl <[e-mail]>]

Nice overview Ales.
Just want to add that I have nothing against the below statements, I fully support them, however, as you mention below requesting IA_NA should be expected by every operator, but the thing is that it should not be depending on check X, Y and Z prior of doing that.  Just request/don't request, and get / don't get it back, perfectly fine.
WRT to the fact that some operators explicitly don't want to sent RA on PPP links.  We can cope with those too, no worries, however, I was just warning about the fact that this happens in real life, not that is should be done like that or not.  Is it "stupid" ?  I don't know, whoami to judge ?   Same goes for DAD on PPP links: do or don't  ?

Regs
Carl

Hi,

let me comment from a mobile operator perspective.

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of STARK, BARBARA H
Sent: Monday, January 09, 2012 5:39 PM
To: Wuyts Carl; Ray Hunter
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

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 listed expectations so far comply with 3GPP networks at the scenario setting level.

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.

The above is actually more or less aligned with 3GPP networks, which is fine, except that it does not spell out the exclusion case
(as already pointed out on the list earlier, the exclusion case is not 3GPP specific and could be used in other deployments as well).

That means that the delegated prefix in IA_PD might be just half of the reserved prefix to the subscription, in order for the PGW
to be able to do the aggregation of the PDN connection /64 prefix and the delegated prefix to a single prefix.

So it can work, but for the network to be 'sure' things work right, it has to waste some address space with the above mentioned work-around.

Does the 6204bis design team have a clear view on the OPTION_PD_EXCLUDE as specified in draft-ietf-dhc-pd-exclude?

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

Cheers,
Ales