Subject: [v6ops] Section 4.4 of 6204-bis

From: Mark Townsley <[email-masked]>
Date: Thu, 1 Dec 2011 12:22:28 +0100

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.

Thanks,

- Mark

> 4.4.  Transition Technologies Support
> 
> 4.4.1.  6rd
> 
>    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:

When DS-Lite is configured, it is represented as a virtual interface that happens to only have IPv4 configured on it. When 6rd is configured it is an interface that just happens to only have IPv6 configured on it. If the ISP configures native IPv4 at the same time, that's it's business. If the ISP configures native IPv6 at the same time, that's also it's business. The CPE should accept these configurations, advertise prefixes and assign addressed on the LAN side accordingly, and then ensure that when packets are sent upstream they get sent to the right native or virtual interface (and associated RIB) and forwarded accordingly. The upstream decisions are based on source routing, longest prefix match, and metrics for each of the interfaces for which we define the defaults for. The virtual interfaces handle how to encap, decap, NAT, not-NAT, etc. 

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. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 10:45:57 -0600

Mark,

Thanks for the review.  Comments below.  Chris, Barbara, and Lorenzo,
please see some responses below that you could also reply to.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Thursday, December 01, 2011 6:22 AM
To: [email-masked] Operations
Subject: [v6ops] Section 4.4 of 6204-bis

 

 

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

>   [RFC5969 <http://tools.ietf.org/html/rfc5969> ].
 
This is an editorial nit.  Chris Donley added the text to give some
perspective to the CPE router vendor.   "Just making the document
longer" is a nit as well.   I am open either way.   

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

The WAN keyword is used to point out that the CE router does not
initiate 6rd in the LAN segment.   It is crystal clear the 6rd virtual
interface is a virtual network interface and such an interface is not
bound to any physical interface.  However, the traffic from the 6rd
virtual interface uses the WAN physical interface to reach the SP.
Thus I think this is a nit and the text in rfc6204bis stays.

>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?

Agree.  Barbara can comment as well since she provided such text.

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

Agree.

 
>Singh, et al.             Expires May 25, 2012                 [Page
13]
  <http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03#page-14> 

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

How does BBF specify the CE router gets configured to go directly to
other destinations?  

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

When the future mcast over 6rd document gets to be an RFC, the CPE
router document also changes.  Till that happens, this bullet stays.

>           ([RFC6333 <http://tools.ietf.org/html/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? 

Implementations do stupid things and thus it's good to specify such
text.  At the Taipei IETF during a hallway conversation between myself,
Lorenzo, Ole, and some others, I heard Lorenzo say, "it's good to
include rules such as this one."  Lorenzo can keep me honest.

 

 

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

>   specified in [RFC6333 <http://tools.ietf.org/html/rfc6333> ].
 
Same reply as above.  Am open to change.  Chris added such text.  He can
reply. 

>           [RFC6333 <http://tools.ietf.org/html/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. 

Same response as earlier about the same comment for 6rd text.   WAN
separates from the LAN of the CPE.  Text stays.

I and reply to other comments in another set of emails.

Thanks,

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 1 Dec 2011 13:44:25 -0500

In-line, marked with <bhs>.

Barbara

<bhs>Because the MSOs said they didn't want to implement manual
configuration in their devices. So we compromised on language that would
provide them an exclusion, but make sure they capability was present in
devices where it was actually needed.

<bhs> Nothing prohibits DHCPv4 configuration after IPCP. I don't see
anything that says it's not allowed. However, it can't be assumed, since
almost no PPP-based access network runs a DHCPv4 server for
PPP-connected customers. And any ISP who isn't running a DHCPv4 server
today, is *highly* unlikely to add one just for 6rd. Remember, the
promise of 6rd is that it doesn't require upgrades to existing
infrastructure in the access network. To suggest that this CE router
draft somehow can require PPP access networks to add DHCPv4 servers in
order to do 6rd is a non-starter. In my experience, CE router vendors
are looking for realistic advice, and not purist recommendations that
are not representative of the real world.

Agree.

<bhs> See above comment. 

<bhs> Via TR-069, or manually. It would be nice if it could also be via
DHCPv4 option, but the companies asking for this don't really see the
lack of a DHCPv4 option as being a showstopper.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 13:11:24 -0600

Mark,

 

 

 

>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?

Higher admin distance means lower priority and hence the DS-Lite tunnel
has lower priority when both native IPv4 and DS-Lite run concurrently.
There is nothing to discuss about IPv6 for this bullet.

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

See Wes's reply to Brian Carpenter in v6ops.  We wanted the cheap CPE
router to have a simple algorithm to forward packets when native IPv6
and 6rd have different prefixes.  The algorithm is checking the source
address of the packet.   Why is the text not complete and instead close?
Source-address based switching is in line with PBR (switching on source
address bit) that multihoming will require.   We wanted to stay away
from the general multihoming requirement.  If you can please suggest
some text that could change the bullet from close to complete that would
help much. 

 
>Singh, et al.             Expires May 25, 2012                 [Page
15]
  <http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03#page-16> 

>   described in Section 5.5.3
<http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03#section-5.5.3> ,
(e) of [RFC4862 <http://tools.ietf.org/html/rfc4862> ].  

>"The CE route MUST immediately advertise the 6rd prefix.... "  when?
when "during a sunsetting activity" ? 

Of course, during a sunsetting activity - the paragraph starts with
"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 CPE completes DHCPv4 renewal process and does not receive any 6rd
option in DHCPv4.  At this juncture, the 6rd prefix is deprecated.  It
is the SP's configuration to pick higher value for DHCPV4 lease_time vs.
the 6rd prefix lifetime.  A retail CPE performs NUD (section 8 of RFC
5969) and NUD does not get replied to.  The retail CPE deprecates the
6rd prefix. 

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

We too want to keep rules simple, but deprecation also involves the LAN
segment and RFC 4862's two-hour rule.   Further, you missed the "during"
the deprecation process when 6rd and native IPv6 run concurrently.
Thus there is no over-specification that I can see.

>Due to the two hours
>   rule specified in [RFC4862 <http://tools.ietf.org/html/rfc4862> ],
the 6rd and the native IPv6 prefix will
>   coexist in the home network.  The two hours rule specified in
section
<http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03#section-5.5.3> 
>   5.5.3
<http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03#section-5.5.3>
of [RFC4862 <http://tools.ietf.org/html/rfc4862> ] causes any deprecated
prefix to linger on the node
>   includes text in bullet L-14 in section 4.3
<http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03#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. 

We have difference in opinion.  We want to define specific behavior for
a cheap CPE while you want generic requirements that make implementation
rules fuzzy to CPE implementers.   We cannot punt to general
multihoming/renumbering procedures that maps to many complex devices and
complex networks.  

>I'm afraid that the requirements as written will lead to a lot of
inconsistency. 

What specific inconsistency do we have with the current text?

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 13:47:03 -0600

Mark,

 

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

We had text for this bullet to say that the CPE sends to the host a SAS
Policy Table but could not get consensus on the design team to include
the term of "SAS Policy Table".   The 6man WG has a draft on
distribution of SAS Policy Table via DHCP.   Another distribution
mechanism is manual where the user checks the CPE router and see that
6rd has prefix A and native IPv6 has prefix B and thus provisions the
host SAS Policy Table to prefer native IPv6 over 6rd.  The rule that you
specified in v6ops can also be folded in the host SAS Policy Table.  

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Thu, 1 Dec 2011 20:56:44 +0100

On Dec 1, 2011, at 7:44 PM, STARK, BARBARA H wrote:

> >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.
>  
> <bhs>Because the MSOs said they didn’t want to implement manual configuration in their devices.

> So we compromised on language that would provide them an exclusion, but make sure they capability was present in devices where it was actually needed.

Ah, so if the router supports PPP, it MUST have manual config. If it doesn't support PPP, it really should not have manual config? 

So now the document has hidden Cable vs. DSL origin requirements, with PPP as the switch for which is being catered too. 

This kind of wiggle-wording might seem clever from the operational side, but from the vendor side it's extremely annoying if not completely out of touch. Either you guys want custom devices, in which case you really don't need well-defined standards specs, or you want standards so that we don't have to build different versions for different types of ISPs (we call that "splatter", and it's absolutely something that hurts the retail side when it comes to building these things on a budget that can work across a myriad of SP environments). 

Manual config is either a requirement or not, tying it to DHCP, PPP, 3GPP, or anything else is making this document more complex, and the job of the vendors more difficult (read: more expensive for consumers). 

> <bhs> Nothing prohibits DHCPv4 configuration after IPCP. I don’t see anything that says it’s not allowed. However, it can’t be assumed, since almost no PPP-based access network runs a DHCPv4 server for PPP-connected customers. And any ISP who isn’t running a DHCPv4 server today, is *highly* unlikely to add one just for 6rd. Remember, the promise of 6rd is that it doesn’t require upgrades to existing infrastructure in the access network. To suggest that this CE router draft somehow can require PPP access networks to add DHCPv4 servers in order to do 6rd is a non-starter. In my experience, CE router vendors are looking for realistic advice, and not purist recommendations that are not representative of the real world.

There is a draft on how to add this to PPP IPCP. If that's easier than DHCP, I'd like to hear it, but I usually hear that the BNG vendors can't be bothered to add a new option to IPCP. Also there is the pushback that pppext is likely to give, though I'm with you on the "realistic advice" side: if adding this to PPP IPCP will help you deploy IPv6 to more customers sooner, and your vendors will comply, let's do it.

BTW,  BNGs can *be* the DHCP server and return a reply that consists of nothing but option 212 (and not worrying about the IP address lease part). That doesn't require new "DHCP infrastructure", at least not in the sense of new DHCP servers. 

> >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. 
>  
> Agree.
>  
> <bhs> See above comment.
> 
Please read http://tools.ietf.org/html/draft-freedman-pppext-ipv6-6rd-00

> >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. 
> 
> How does BBF specify the CE router gets configured to go directly to other destinations? 

It just did, I suppose. In TR-124-something, right?

>  
> <bhs> Via TR-069, or manually. It would be nice if it could also be via DHCPv4 option, but the companies asking for this don’t really see the lack of a DHCPv4 option as being a showstopper.
>  

Right, when it was added it to BBF docs rather than starting with the IETF, it effectively became a BBF-only, largely TR-69-only, thing. That's fine, but that makes circling the requirement back around to the root, a problem. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 14:48:42 -0600

Mark,

 
 >          [RFC6334 <http://tools.ietf.org/html/rfc6334> ] to configure
the DS-Lite tunnel.  The IPv6 CE

 
>Singh, et al.             Expires May 25, 2012                 [Page
14]
  <http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03#page-15> 

>           space specified in [RFC5735
<http://tools.ietf.org/html/rfc5735> ], then the IPv6 CE Router SHOULD

>This is very bad direction.

No.

>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 does the text say both of public IPv4 and private IPv4?  The text
only says that if the CPE router is deployed in a native IPv4
deployment, the CPE has no use for DS-Lite and the CPE should disable
DS-Lite.   Not all IPv4 deployments are IPv4 address depleted and that
is what the CPE does in such a deployment.  Please see more of my
responses below as well. 

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

See the Coexistence section which is section 4.4.3 in rfc6204bis and
bullets 1 and 3.  Of course, by default DHC (v4 or v6) tries forever.
In bullet 1, DHC is one means the CPE WAN uses to acquire a native IPv4
address.  While DHCPv4 tries forever, if DHCPv6 completes and the CPE is
issued DS-Lite parameters via DHCPv6 or DS-Lite is manually configured
on the CPE, the CPE turns on DS-Lite and stops DHCPv4.  No DHCP storm.

>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!

If the CPE uses native IPv4 the CPE does need a public IPv4 address on
the WAN because the CPE has to do NAT44.  

>- I see a possible conflict here with the /10 space that may or may not
be allocated for CGN deployment.

Francois-Xavier Le Bail in v6ops asked to use rfc 5735 and I agree with
him.   If Francois-Xavier agrees to move back to 1918, we can change the
text.  There can be any number of possible conflicts in the future but
we have to start somewhere for private IPv4 address space.  That is why
the requirement was changed from a MUST to a SHOULD.  

>Why not? As with the similar 6rd requirement, please just leave this
out. Why hamstring future efforts to define multicast here?

When future comes and an RFC is available, the text will change.  Till
then it is good to keey multicast data out of IP transition tech.

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

Same response as the response I gave in an earlier email today to 6RD-5.
The response is reproduced below.

"Implementations do stupid things and thus it's good to specify such
text.  At the Taipei IETF during a hallway conversation between myself,
Lorenzo, Ole, and some others, I heard Lorenzo say, "it's good to
include rules such as this one."  Lorenzo can keep me honest."

Hemant

---

From: Chris Donley <[email-masked]>
Date: Thu, 1 Dec 2011 17:06:27 -0700

Mark,

Please see in-line (marked with [CD]).

Chris
From: Mark Townsley <[email-masked]<mailto:[email-masked]>>
Date: Thu, 1 Dec 2011 12:56:44 -0700
To: "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
Cc: Hemant Singh <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Chris Donley <[email-masked]<mailto:[email-masked]>>, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Section 4.4 of 6204-bis

[CD] We don't specify manual config for anything in eRouter.  We certainly don't want to add a UI just for 6rd, especially since native IPv6 is defined in DOCSIS 3.0.

So now the document has hidden Cable vs. DSL origin requirements, with PPP as the switch for which is being catered too.
[CD] That was in original 6204, as well.  Cable/DSL provisioning models are similar, but there are key differences, in particular around WAN-side provisioning. DOCSIS specifies the use of DHCPv6 (only), whereas BBF includes additional options.

This kind of wiggle-wording might seem clever from the operational side, but from the vendor side it's extremely annoying if not completely out of touch. Either you guys want custom devices, in which case you really don't need well-defined standards specs, or you want standards so that we don't have to build different versions for different types of ISPs (we call that "splatter", and it's absolutely something that hurts the retail side when it comes to building these things on a budget that can work across a myriad of SP environments).
[CD] Would you rather we said implement eRouter AND TR-124? I think that would be more confusing. 6204bis is a compromise that fits both provisioning models reasonably well.

Manual config is either a requirement or not, tying it to DHCP, PPP, 3GPP, or anything else is making this document more complex, and the job of the vendors more difficult (read: more expensive for consumers).
[CD] As I said, we don't want to require a UI just for 6rd, which in a cable environment, would only be needed for pre-DOCSIS 3.0 systems.  However, BBF does need manual config for PPP.

Agree.

<bhs> See above comment.

- Mark

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 1 Dec 2011 19:04:46 -0500

Inline, marked with <bhs2> this time.

Barbara

Ah, so if the router supports PPP, it MUST have manual config. If it
doesn't support PPP, it really should not have manual config? 

<bhs2> Not quite. If it supports PPP it MUST have manual config. If it
doesn't support PPP, this document makes no statement as to whether or
not it should have manual config. Which means a device without PPP that
has manual config would still be compliant with 6204bis. It would also
be compliant if it doesn't have manual config. If you're designing a
device that doesn't do PPP, you're already building a device that's
"custom" to only work in DHCP environments. So I don't see why there
should be a problem with saying "if you are adding PPP support to your
device, add manual config for 6rd, too". If you don't want to support
PPP, then don't. BTW, we already have an existing "if PPP" requirement:
"WLL-2:  If the WAN interface supports PPP encapsulation, the IPv6 CE
router MUST support IPv6 over PPP [RFC5072]." So I fail to see the
problem.

So now the document has hidden Cable vs. DSL origin requirements, with
PPP as the switch for which is being catered too. 

This kind of wiggle-wording might seem clever from the operational side,
but from the vendor side it's extremely annoying if not completely out
of touch. Either you guys want custom devices, in which case you really
don't need well-defined standards specs, or you want standards so that
we don't have to build different versions for different types of ISPs
(we call that "splatter", and it's absolutely something that hurts the
retail side when it comes to building these things on a budget that can
work across a myriad of SP environments). 

Manual config is either a requirement or not, tying it to DHCP, PPP,
3GPP, or anything else is making this document more complex, and the job
of the vendors more difficult (read: more expensive for consumers). 

There is a draft on how to add this to PPP IPCP. If that's easier than
DHCP, I'd like to hear it, but I usually hear that the BNG vendors can't
be bothered to add a new option to IPCP. Also there is the pushback that
pppext is likely to give, though I'm with you on the "realistic advice"
side: if adding this to PPP IPCP will help you deploy IPv6 to more
customers sooner, and your vendors will comply, let's do it.

BTW,  BNGs can *be* the DHCP server and return a reply that consists of
nothing but option 212 (and not worrying about the IP address lease
part). That doesn't require new "DHCP infrastructure", at least not in
the sense of new DHCP servers. 

<bhs2> Not interested in upgrading the BNG. Any configuration changes
and software updates to the BNG must be tested very carefully. That
takes a lot of time and effort. The potential benefit does not outweigh
the cost of time spent in such testing, together with the risk of bad
things happening. When introducing a function into the access network
that will be visible to all attached devices, you never, ever assume
that everything will just work, without problem. And in this case, there
is a wide variety of off-the-shelf IPv4 CE routers that are being used
for this attachment. Anything that might possibly, conceivably break
existing IPv4 for any of these customers has to be done very, very
carefully. Risk mitigation for IPv6 and 6rd is to turn them off and go
back to IPv4. Risk mitigation for broken IPv4 doesn't exist.

---

From: Chris Donley <[email-masked]>
Date: Mon, 5 Dec 2011 08:33:39 -0700

Chris

From: Hemant Singh <[email-masked]<mailto:[email-masked]>>
Date: Thu, 1 Dec 2011 09:45:57 -0700
To: Mark Townsley <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Chris Donley <[email-masked]<mailto:[email-masked]>>, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>, "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] Section 4.4 of 6204-bis

Mark,

Thanks for the review.  Comments below.  Chris, Barbara, and Lorenzo, please see some responses below that you could also reply to.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: Thursday, December 01, 2011 6:22 AM
To: [email-masked]<mailto:[email-masked]> Operations
Subject: [v6ops] Section 4.4 of 6204-bis

>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.
[CD] Since 6RD is a "SHOULD", we're trying to provide some context for vendors who might not closely follow the IETF as to why they might want to implement this and how. Same with DS-Lite below.

>   [RFC5969<http://tools.ietf.org/html/rfc5969>].

This is an editorial nit.  Chris Donley added the text to give some perspective to the CPE router vendor.   “Just making the document longer” is a nit as well.   I am open either way.

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

The WAN keyword is used to point out that the CE router does not initiate 6rd in the LAN segment.   It is crystal clear the 6rd virtual interface is a virtual network interface and such an interface is not bound to any physical interface.  However, the traffic from the 6rd virtual interface uses the WAN physical interface to reach the SP.   Thus I think this is a nit and the text in rfc6204bis stays.

Agree.

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

When the future mcast over 6rd document gets to be an RFC, the CPE router document also changes.  Till that happens, this bullet stays.

>           ([RFC6333<http://tools.ietf.org/html/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?

Implementations do stupid things and thus it’s good to specify such text.  At the Taipei IETF during a hallway conversation between myself, Lorenzo, Ole, and some others, I heard Lorenzo say, “it’s good to include rules such as this one.”  Lorenzo can keep me honest.

[CD] Right. In our lab, I've seen too many times that such strange feature interactions do occur.  I can foresee a device that gets both 6rd and ds-lite configuration, tries to bring up both tunnels, and sets up routes so that one tunnel will flow through the other.  I heard of an implementation that shuts down the native interface when it gets a tunnel config. If such a thing were to happen, I want to avoid the conversation of "where in 6204bis does it say we shouldn't forward 6rd through ds-lite (or vice-versa)."

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

>   specified in [RFC6333<http://tools.ietf.org/html/rfc6333>].

Same reply as above.  Am open to change.  Chris added such text.  He can reply.

[CD] Same as above – for people who don't regularly follow RFCs, this provides context as to why a vendor might want to implement DS-Lite (and yes, there are questions).

>           [RFC6333<http://tools.ietf.org/html/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.

Same response as earlier about the same comment for 6rd text.   WAN separates from the LAN of the CPE.  Text stays.

Thanks,

Hemant