I finally got a chance to go through section 4.4 and provide specific comments. In short, it should come as no surprise that I think this section needs work. Please see inline as well as the conclusion towards the end.
4.4. Transition Technologies Support
The IPv6 CE Router can be used to offer IPv6 service to a LAN, even
when the WAN access network only supports IPv4. One technology that
supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment
(6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside
IPv4 at the IPv6 CE Router and sends it to a Service Provider Border
Relay (BR). The IPv6 CE Router calculates a 6rd delegated IPv6
prefix during 6rd configuration, and sub-delegates the 6rd delegated
prefix to devices in the LAN.
IMHO, the above is just making the document longer. You can simply include the sentence below. RFC 5969 is a normative, so you can rely on the reader to go read it.
The IPv6 CE Router SHOULD implement 6rd functionality as specified in
[RFC5969].
6rd requirements:
6RD-1: If the IPv6 CE Router implements 6rd functionality, the CE
Router WAN interface MUST support at least one 6rd Virtual
Interface.
6rd is implemented with a "6rd virtual interface" (see terminology section of RFC 5969) which is not bound to a WAN interface as you are suggesting in this requirement. I would remove the requirement altogether, as it is part of RFC 5969 anyway, and by re-specifying we run the risk of introducing inconsistencies.
6RD-2: If the IPv6 CE router implements 6rd functionality, it MUST
support 6rd configuration via the 6rd DHCPv4 Option (212) and
if the IPv6 CE router is capable of automated configuration
of IPv4 through IPCP (i.e., over a PPP connection), it MUST
support user-entered configuration of 6rd.
Why not just say it MUST support DHCPv4 option 212 and Manual configuration and stop at that? If we are going to include manual config, it is effectively *always* an option, not just for PPP or any other type of access link. Just make it a MUST and be done.
Further, if we are going to mention PPP, rather than falling back to manual only, why not allow DHCP configuration after PPP IPCP is finished?
From RFC2131: "DHCPINFORM - Client to server, asking only for local configuration parameters; client already has externally configured network address."
Back when the PPP folks actively decided to stop duplicating DHCP functionality in IPCP, this was the recommended approach (and Windows stacks and the like actually try to obtain additional parameters for PPP connections after IPCP comes up, though often the network does not have any additional parameters to give...). This gives PPP connections a pretty decent chance to work with 6rd automatically, using the same DHCP configuration as non-PPP.
The IPv6 CE
router MAY use other mechanisms to configure 6rd parameters.
Such mechanisms are outside the scope of this document.
Seems obvious, but OK.
6RD-3: If the CE router implements 6rd functionality, it MUST allow
the user to specify whether all IPv6 traffic goes to the 6rd
Border Relay, or whether IPv6 traffic to other destinations
within the same 6rd domain are routed directly to those
Singh, et al. Expires May 25, 2012 [Page 13]
Internet-Draft IPv6 CE Router Requirements November 2011
destinations. The CE router MAY use other mechanisms to
configure this. Such mechanisms are outside the scope of
this document.
Do you really mean the "user" is supposed to be able to specify whether IPv6 traffic always going through the BR, or the "operator" is supposed to be able to specify this?
This behavior, while straight-forward to implement as it is effectively removing a more-specific route on the 6rd virtual interface, is out of scope of RFC 5969 as currently defined. There is no way to specify this in DHCPv4 configuration. One might be able to configure this from the network with PIO or DHCPv6 route options in a general manner, but this hasn't been specified anywhere that I am aware of within the context of 6rd. I understand the BBF has included some specifics around this, and perhaps it is best if those requirements stay in the BBF or at least we provide a reference to them from here. Otherwise, this requirement remains under-specified as written, and if expounded would effectively be an update (in the formal sense) to RFC 5969.
6RD-4: If 6rd is operational on the IPv6 CE Router, multicast data
MUST NOT be sent on any 6rd tunnel.
As long as the high-level requirement is RFC 5969 only, there is no need to mention multicast. If in the future someone implements 6rd multicast (there are drafts on it), why stop them? Best to just remove this (non-)requirement from the document.
6RD-5: The CE Router MUST NOT forward 6RD traffic over a DS-Lite
([RFC6333]) tunnel.
Again, why over-specify? Sure, the operational steps you take should not lead you down this path, but if the router is following a logical set of routing and virtual interface constructs, this would just work. Why make the CE vendor go out of their way to check to see if this is happening and drop packets?
4.4.2. Dual-Stack Lite(DS-Lite)
Even as users migrate from IPv4 to IPv6 addressing, a significant
percentage of Internet resources and content will remain accessible
only through IPv4. Also, many end-user devices will only support
IPv4. As a consequence, Service Providers require mechanisms to
allow customers to continue to access content and resources using
IPv4 even after the last IPv4 allocations have been fully depleted.
One technology that can be used for IPv4 address extension is DS-
Lite.
DS-Lite enables a Service Provider to share IPv4 addresses among
multiple customers by combining two well-known technologies: IP in IP
(IPv4-in-IPv6) tunneling and Carrier Grade NAT. More specifically,
Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at
the IPv6 CE Router and sends it to a Service Provider Address Family
Transition Router (AFTR). Configuration of the IPv6 CE Router to
support IPv4 LAN traffic is outside the scope of this document.
IMHO - As with the 6rd "summary" text, I think the most important line is the following one, and the previous paragraphs may be omitted or shrunk to one or two lines at best.
The IPv6 CE Router SHOULD implement DS-Lite functionality as
specified in [RFC6333].
WAN requirements:
DLW-1: To facilitate IPv4 extension over an IPv6 network, if the CE
Router supports DS-Lite functionality, the CE Router WAN
interface MUST implement a B4 Interface as specified in
[RFC6333].
As with the "6rd interface" case, this really seems repetitive. It should be sufficient to say "implement DS-Lite" ... Also, virtual interfaces are not tied to any physical interfaces per se, they exist independently. They may be used for WAN connectivity, but they are a fully separate interface in terms of the RIB and such.
DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the
CE Router MUST support using a DS-Lite DHCPv6 option
[RFC6334] to configure the DS-Lite tunnel. The IPv6 CE
Router MAY use other mechanisms to configure DS-Lite
parameters. Such mechanisms are outside the scope of this
document.
Singh, et al. Expires May 25, 2012 [Page 14]
Internet-Draft IPv6 CE Router Requirements November 2011
DLW-3: IPv6 CE Router MUST NOT perform IPv4 Network Address
Translation (NAT) on IPv4 traffic encapsulated using DS-Lite.
DLW-4: If the IPv6 CE Router is configured with a public IPv4
address on its WAN interface, where public IPv4 address is
defined as any address which is not in the private IP address
space specified in [RFC5735], then the IPv6 CE Router SHOULD
disable the DS-Lite B4 element.
This is very bad direction.
DS-Lite was designed to combat Private IPv4 Address Exhaustion, and you have a requirement that talks about the CPE receiving not only a Public but a Private IPv4 address and tying specific behavior to that?
Where is the requirement that if DS-Lite is configured, the CPE should not be expected to receive an IPv4 address at all on its WAN interface so that it doesn't hammer the network asking for one? Or, (and perhaps this is better) the recommended way for DHCPv4 (and PPP IPCP) to tell the CPE that it has no IPv4 and not to ask for it (so we don't repeat the "DHCPv6 storm" problem talked about so much here)?
That's what we should be defining here, or you have hamstrung the whole point of DS-Lite which was to reduce the number of IPv4 addresses (public or private!) needed by the access network. The CPE MUST be able to operate in the *absence* of an IPv4 address on its WAN interface! That's the requirement we need here!
Also, specific nits on the above wording (though I think the whole requirement is in question):
- "RFC 5735 private IP address space" is just an indirection to RFC 1918, just call it RFC 1918.
- I see a possible conflict here with the /10 space that may or may not be allocated for CGN deployment.
DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast
data MUST NOT be sent on any DS-Lite tunnel.
Why not? As with the similar 6rd requirement, please just leave this out. Why hamstring future efforts to define multicast here?
DLW-6: The CE Router MUST NOT forward DS-Lite traffic over a 6RD
tunnel.
Why make a requirement on the forwarding path here? Sure, it is probably bad operational practice to configure a CE such that it would end up with a routing path that did this, but this kind of requirement forces the CE to actually check on the forwarding path whether this is occurring and drop the packet if it does. A CE could easily misinterpret this as filtering all Protocol 41 traffic. Not to mention, this could end up becoming a test case for certification.
In general: Let's please avoid making any sort of laundry lists of MUST NOTs around negative cases. We're better off defining MUSTs for things we want to happen.
4.4.3. Transition Technologies Coexistence
Supporting transition technologies that may coexist with native
service requires control over provisioning and sunsetting. Some
guidelines follow:
1. Initiate native IPv4/IPv6 provisioning (e.g. via DHCP)
simultaneously.
2. After IPv4 provisioning completes, if 6rd parameters are obtained
from the DHCPv4 transaction or configured on the device, initiate
6rd.
3. After IPv6 provisioning completes, if DS-Lite parameters are
obtained from the DHCPv6 transaction or configured on the device,
initiate DS-Lite.
4. Routes over the DS-Lite tunnel always have a higher
administrative distance than native IPv4 routes.
higher or lower? Do you want traffic to prefer native or tunneled here? I read this as preferring native IPv4, but perhaps the real goal is to prefer IPv6?
5. Selection of 6rd tunnel or native IPv6 output interface on the CE
router is determined by the source IPv6 address of the packet
from a host, when different prefixes are available over 6rd vs.
native IPv6. If the two interfaces provide the CE router with
the same prefix, then the CE router prefers the native IPv6
interface to the 6rd interface for forwarding traffic out the WAN
when both 6rd and native IPv6 interfaces are active.
This is close, but I think it would be much better to define the multihoming requirements generically and have 6rd just be one special case.
6. The CE router messages to the host the use of native IPv6 in
preference to 6rd, in the case where the two interfaces use
different prefixes.
"CE router messages to the host" - with what, a new protocol? The host does what it wants with the prefixes it has, the router is a slave to its source selection and has to route out the appropriate interface accordingly. This is "the curse of end-to-end" to quote Lorenzo.
During a sunsetting activity such as deprecating 6rd and moving to
Singh, et al. Expires May 25, 2012 [Page 15]
Internet-Draft IPv6 CE Router Requirements November 2011
native IPv6, the IPv6 CE router MUST immediately advertise the 6rd
prefix with a Preferred Lifetime of zero and a Valid Lifetime of the
lower of the current Valid Lifetime and two hours (which must be
decremented in real time) in a Router Advertisement message as
described in Section 5.5.3, (e) of [RFC4862].
"The CE route MUST immediately advertise the 6rd prefix.... " when? when "during a sunsetting activity" ? How do you trigger that in software? As an implementor, I would have no idea what this MUST really means.
The heart of the problem here is *over-specification*. All the CPE needs to do is to deprecate the address when its lifetime expires just like any other prefix. This will happen naturally once the DHCPv4 lease that 6rd was provisioned with expires and no new 6rd option arrives with the renewal (if there is any MUST needed, it's at this stage). So: No special cases. No immediate interrupts to do this or that. No new case() statements specifically for 6rd, 6rd+native, 6rd+native+ds-lite, etc. Just the normal code run through when interfaces come up and down and prefixes are timed out. Nothing special. No surprises.
Due to the two hours
rule specified in [RFC4862], the 6rd and the native IPv6 prefix will
coexist in the home network. The two hours rule specified in section
5.5.3 of [RFC4862] causes any deprecated prefix to linger on the node
even when an RA has sent a Preferred Lifetime of zero to expire the
prefix to the node. During such coexistence of multiple prefixes,
the CE router sends an ICMPv6 error for packets sourced or destined
related to the deprecated prefix. Note this document already
includes text in bullet L-14 in section 4.3 for such a provision.
Pointing out the two hour issue is fine, as well as what to do with deprecated prefixes, but this is *all* normal mutlihoming/renumbering procedures. We would be far better off defining this generally, and letting 6rd + native just fall in line happily as any other case where there are two interfaces with prefixes assigned.
I'm afraid that the requirements as written will lead to a lot of inconsistency. Let's please reuse basic routing design constructs and apply defaults as we need them. For example:
I think this approach will lead to a much simpler set of specific requirements, far more consistency of behavior, and resiliency in the face of variant operational approaches.
RSS Feed