Subject: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 11 Apr 2017 17:11:39 +0200

Hi all,

I got a comment about including support for LISP in order to allow IPv4 access with an IPv6-only-WAN.

Even if I’ve got a couple of links of providers that actually use it, I believe is not something that is happening in the market, and seems to be tied to a specific vendor.

I’m not personally fan of including that support in the document, however I will like to heard some more opinions on that from the WG.

I plan to publish a new version (-01) in 1-2 days, maximum, so I will like to heard opinions about that, and in general for the actual version of the document.

Regards,
Jordi

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Apr 2017 09:23:17 -0700

Speaking as a participant.

I would suggest that any requirements found in the document be *required* by at least one commercial network, preferably several. Vendors and enthusiasts like to stuff requirements documents with their favorite features, and in the products they make they can certainly include them. But for everyone else, and for the networks that don't use them, they are simply cost and a source of bugs.

On Apr 11, 2017, at 8:11 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: [email-masked]
Date: Wed, 12 Apr 2017 11:34:44 +0200

Jordi,

The standardisation of the "transitioning off IPv4 mechanisms" is a prime example of IETF failure.
You are proposing to carry that failure forward and require all CE implementations to implement _all_ the mechanisms in existence?

That is not providing "value add" to the community.

If I remember correctly that list is now: RFC2473, GRE, L2TP, LISP, MAP-E, MAP-T, 4RD, 464XLAT, Public 4over6, LW46, Dynamic LW46, ...

Best regards,
Ole

> On 11 Apr 2017, at 17:11, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi all,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 11:44:46 +0200

Hi Ole,

No, sorry, I guess you misunderstood my email.

I’m NOT in favor of including an unlimited number of mechanisms, and I think we must focus in those that have a real traction. I’m NOT in favor of including LISP.

However, the document is a WG document, so is not just my decision, but the WG, so I must ask the WG opinions before “rejecting” LISP. That was my question.

I think we need to have a balance:
1) Main goal, support of IPv6-only access but allow IPv4 to keep working in the customer’s LANs.
2) Allow the support of “older” IPv6-in-IPv4 (basically 6rd) as it was in the previous version of the document, but moved to MAY. Deployments that today have IPv4-only access, can start deploying IPv6 (in IPv4 if they need it), but use the same CE for when they can move to IPv6-only access.
3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed), based on market relevance and understanding that most of them don’t take additional code in the CPE, because most of this code is basically the same.

So, to make it short, unless there is a “magic” mechanism that I’m not aware of, and the WG decides to include it, my intend is no longer include anything new in the document. And if that “magic” mechanism exists, then we could delete all the others.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 12 de abril de 2017, 11:34
Para: <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    Jordi,

    
    
    Best regards,
    Ole

---

From: [email-masked]
Date: Wed, 12 Apr 2017 12:56:39 +0200

Jordi,

> 2) Allow the support of “older” IPv6-in-IPv4 (basically 6rd) as it was in the previous version of the document, but moved to MAY. Deployments that today have IPv4-only access, can start deploying I…

Which is a bit ironic with regards to 6RD which is one of the few mechanisms with real deployment, as in millions and millions of users.

>3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed), based on market relevance and understanding that most of them don’t take additional code in the CPE, because most of this cod…

That statement is not quite true. The various mechanisms while largely being built out of the same parts, require quite a bit of glue, testing and additional support for configuration. If you think the conflict around hosts/network DNS recursive resolver configuration is hard, then this is a n-square problem.

For implementation complexity just compare MAP-T and MAP-E/LW46 in:
https://git.fd.io/vpp/tree/src/vnet/map

> So, to make it short, unless there is a “magic” mechanism that I’m not aware of, and the WG decides to include it, my intend is no longer include anything new in the document. And if that “magic” m…

The magic is in us having the balls to make a choice. And pick one mandatory to implement mechanism. And only one.

Cheers,
Ole

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 11:30:32 +0000

Hi Ole, 

I tend to agree with you but with a slightly different proposal:  pick ONE mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P mechanism (MAP-E). 

FWIW, the following tables recap the required functionality to be supported by the CPE for DS-Lite, lw4over6, and MAP-E + required provisioning information for each of them.

   +--------------+----------------+-----------------+-----------------+
   |   Functional |  IPv4-in-IPv6  | Port-restricted | Port-restricted |
   |      Element |     tunnel     |       IPv4      |      NAT44      |
   |              |    endpoint    |                 |                 |
   +--------------+----------------+-----------------+-----------------+
   |           B4 |      Yes       |       No        |       No        |
   |         lwB4 |      Yes       |       Yes       |       Yes       |
   |     MAP-E CE |      Yes       |       Yes       |       Yes       |
   +--------------+----------------+-----------------+-----------------+

                        Table x: Supported Features

         +---------+---------------------------------------------+
         |    Mode | Provisioning Information                    |
         +---------+---------------------------------------------+
         | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint Address |
         |   Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint Address |
         |         | IPv4 Address                                |
         |         | Port Set                                    |
         |   MAP-E | Mapping Rules                               |
         |         | MAP Domain Parameters                       |
         +---------+---------------------------------------------+

                     Table x: Provisioning Information
Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : mercredi 12 avril 2017 12:57
> À : [email-masked]
> Cc : [email-masked]
> Objet : Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
> 
> Jordi,
> 
> > I’m NOT in favor of including an unlimited number of mechanisms, and I
> think we must focus in those that have a real traction. I’m NOT in favor
> of including LISP.
> >
> > However, the document is a WG document, so is not just my decision, but
> the WG, so I must ask the WG opinions before “rejecting” LISP. That was my
> question.
> >
> > 2) Allow the support of “older” IPv6-in-IPv4 (basically 6rd) as it was
> in the previous version of the document, but moved to MAY. Deployments
> that today have IPv4-only access, can start deploying IPv6 (in IPv4 if
> they need it), but use the same CE for when they can move to IPv6-only
> access.
> 
> Which is a bit ironic with regards to 6RD which is one of the few
> mechanisms with real deployment, as in millions and millions of users.
> 
> >3) Support a subset of IPv4-in-IPv6 (from all those that IETF designed),
> based on market relevance and understanding that most of them don’t take
> additional code in the CPE, because most of this code is basically the
> same.
> 
> That statement is not quite true. The various mechanisms while largely
> being built out of the same parts, require quite a bit of glue, testing
> and additional support for configuration. If you think the conflict around
> hosts/network DNS recursive resolver configuration is hard, then this is a
> n-square problem.
> 
> > So, to make it short, unless there is a “magic” mechanism that I’m not
> aware of, and the WG decides to include it, my intend is no longer include
> anything new in the document. And if that “magic” mechanism exists, then
> we could delete all the others.
> 
> The magic is in us having the balls to make a choice. And pick one
> mandatory to implement mechanism. And only one.
> 
> Cheers,
> Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Apr 2017 12:47:11 +0000

> Which is a bit ironic with regards to 6RD which is one of the few mechanisms
> with real deployment, as in millions and millions of users.

The reason I've said I have no problem with backing off 6rd in this document is because I see this document as primarily driving retail devices. The only successful deployments I'm aware of rely on ISP-procured, supplied, and managed devices. No change to 6rd requirements is happening in BBF TR-124.

I have serious doubts that any transition mechanism can be successful if the customer must take any action, whatsoever, to specifically enable it.

Which means I think dual stack is the only scenario it is reasonable to require in retail routers. All retail router implementations I've seen of transition mechanisms require users to (1) have purposefully sought out a router that supports IPv6, (2) know they need a router that supports a specific transition technology, (3) have carefully researched specifically which routers support that particular transition technology (because it won't be listed on the packaging), and (4) enable the transition technology.

Because this customer behavior is so unlikely, it's irrelevant whether or not a retail router supports 6rd. 
In fact, any transition technology that does not ship enabled, simultaneous with dual stack, is irrelevant in retail devices.
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Apr 2017 12:52:45 +0000

> I tend to agree with you but with a slightly different proposal:  pick ONE
> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P
> mechanism (MAP-E).

Because RFC 7084 is also used as a mandatory reference in BBF TR-124 (used by telco ISPs to help with CE router RFPs), and most ISPs have no interest in requiring capabilities that are not useful to or relevant in their deployment, there MUST NOT be any mandatory transition mechanisms included in a 7084-bis.
Barbara

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Apr 2017 15:03:43 +0200 (CEST)

> In fact, any transition technology that does not ship enabled, simultaneous with dual stack, is irrelevant in retail devices.

I know of ISPs who send DHCP option 212 to (some) customers. Their IPv6 
enablement rate seems to hover around 1%.

So there seems to be devices out there that support 6RD out of the box, 
but they're such a small minority that I agree that this IPv6 "rollout" 
can't be counted as "successful".

My view on 7084 is that it's a "laundry list", which ISPs can use to 
assist them in successfully procuring residential gateways. So I find it 
useful that it contains lots of stuff, but then perhaps the title 
shouldn't be "basic requirements" anymore, but perhaps something else.

Oles point on it becoming quite extensive is valid. Perhaps we should 
re-focus it to be a document that says "if you want to support X, do 
REQ1-REQ9". I still think it's good input to both people procuring 
gateways, and people implementing gateways. Not all have the resources to 
create that 5000+ lines of requirements whenever they procure a new 
gateway, or large enough that they would get any attention from vendors 
even if they had such a list.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Wed, 12 Apr 2017 13:12:31 +0000

Hi Barbara, 

Wouldn't just be fine for those ISPs not interested in transition mechanisms to continue referring to RFC7084?

Cheers,
Med

> De : STARK, BARBARA H [mailto:[email-masked]]
> Envoyé : mercredi 12 avril 2017 14:53
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked];
> [email-masked]
> Cc : [email-masked]
> Objet : RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
> 
> Because RFC 7084 is also used as a mandatory reference in BBF TR-124 (used
> by telco ISPs to help with CE router RFPs), and most ISPs have no interest
> in requiring capabilities that are not useful to or relevant in their
> deployment, there MUST NOT be any mandatory transition mechanisms included
> in a 7084-bis.
> Barbara

---

From: Philip Homburg <[email-masked]>
Date: Wed, 12 Apr 2017 15:14:33 +0200

>In fact, any transition technology that does not ship enabled, simultaneous wi
>th dual stack, is irrelevant in retail devices.

I have a strong preference for dual stack, so in that sense I don't
particularly care about transtition mechanisms, but that said...

Since for ever, I have been able to buy retail routers that support an insane
number of ways to configure ADSL or VDSL. For ADSL you need at least
VPI and VCI, and encapsulation mode. For VDSL you often need to configure
the VLAN number and whether to use PPPoE or not. In addition you may have
to configure user name and password for PPP variations.

Surprisingly, despite the fact that consumers are utterly incapable of 
configuring those parameters, these routers can be easily bought retail.

Some vendors are cheating though. Some of them spell out the parameters for
different ISPs in the manual. Others go even further and have a configuration
wizzard where you just select your ISP.

Note that in some cases, the ISP supplied device doesn't do what you want.
Then it is good if there are retail devices that support your ISP's choice 
of protocols. So for me it is weird to say that just because all relevant
ISPs provide a 6rd capable router, there is no need for that protocol in a
retail device. Retail devices should support protocols popular in the
region where the device is sold. 

Here, one ISP refuses to provide bridge mode in the cable modem when IPv6
is enabled because not all (or too few) retail routers support the
transitioning technology they are using.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Apr 2017 13:15:21 +0000

> to continue referring to RFC7084?

Currently, the draft is written as a -bis to RFFC 7084, with the intent to obsolete RFC 7084 when it is published.
If this is done, then, no, continued referencing of RFC 7084 would not be appropriate.

If a different approach is taken that leaves RFC 7084 alone, I would agree.
Barbara

---

From: Ca By <[email-masked]>
Date: Wed, 12 Apr 2017 13:50:17 +0000

Ole

On Wed, Apr 12, 2017 at 3:56 AM <[email-masked]> wrote:

> think we must focus in those that have a real traction. I’m NOT in favor of
> including LISP.
> >
> in the previous version of the document, but moved to MAY. Deployments that
> today have IPv4-only access, can start deploying IPv6 (in IPv4 if they need
> it), but use the same CE for when they can move to IPv6-only access.
>
> additional code in the CPE, because most of this code is basically the same.
>
> being built out of the same parts, require quite a bit of glue, testing and
> additional support for configuration. If you think the conflict around

Has there yet been a substantial (millions of subs) deployment of any of
those listed ?  I would not say your metric of subjective complexity is
relevant to the current hundreds of millions of subs on v6 or v6-only.

I think map-t may have had some recent deployment at Jio, but it is not
clear to me how much they have used map-t vs DS ... or their v6 numbers in
mobile vs landline.

<https://git.fd.io/vpp/tree/src/vnet/map>
> anything new in the document. And if that “magic” mechanism exists, then we
> could delete all the others.
>

Disagree. This idea of a standard is neither true for ipv4 networks or ipv6
networks. You make standards for interop and design validation, not
picking a universal solution.  Neither have seen one magic choice in
routing protocols, L2 encap, security strategy, v4-v6 transition....

Softwire WG already has seen this approach fail both the working group and
industry several times.  Softwire's approach failed me and my deployment.

Coin flips don't convince anyone of anything aside from your standards
being arbitrary and not driven by practical deployments.

CB

Ps. LISP remains in search of a problem it solves, and has, afaik, not been
used to push ipv6 forward in the real world.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 16:05:27 +0200

Fully agree with Cameron view, and furthermore … if we need to choose one mechanism because how many millions of devices already use it, and this demonstrates the success, clearly 464XLAT has more TENS OF MILLIONS of users than DS-LITE + 6RD + MAP E + MAP T, altogether, and of course it means a single ISP having both wired and cellular networks, can have a single way to deploy IPv6 instead of two.

Regards,
Jordi

-----Mensaje original-----
De: Ca By <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 12 de abril de 2017, 15:50
Para: <[email-masked]>, <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    Ole

    Jordi,

    

    Has there yet been a substantial (millions of subs) deployment of any of those listed ?  I would not say your metric of subjective complexity is relevant to the current hundreds of millions of subs on v6 or v6-only. 
    
    I think map-t may have had some recent deployment at Jio, but it is not clear to me how much they have used map-t vs DS ... or their v6 numbers in mobile vs landline. 

    

    Disagree. This idea of a standard is neither true for ipv4 networks or ipv6 networks. You make standards for interop and design validation, not
    picking a universal solution.  Neither have seen one magic choice in routing protocols, L2 encap, security strategy, v4-v6 transition....
    
    Softwire WG already has seen this approach fail both the working group and industry several times.  Softwire's approach failed me and my deployment. 
    
    Coin flips don't convince anyone of anything aside from your standards being arbitrary and not driven by practical deployments. 
    
    CB
    
    Ps. LISP remains in search of a problem it solves, and has, afaik, not been used to push ipv6 forward in the real world. 

    Cheers,
    Ole

---

From: [email-masked]
Date: Wed, 12 Apr 2017 16:21:16 +0200

> I think map-t may have had some recent deployment at Jio, but it is not clear to me how much they have used map-t vs DS ... or their v6 numbers in mobile vs landline.

Given that none of these mechanisms are interoperable. And that it is difficult to build an ISP provisioning system that can deal with an arbitrary CPE, and that it is hard to build a CPE that can deal with an ISP offering an arbitrary mechanism. The conclusion really has to be the same as Barbara has for the IPv6 over IPV6 mechanisms... and it follows that there is nothing to gain by adding a list of these mechanisms in a 7084bis document.

Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 17:08:32 +0200

Hi Barbara,

Maybe I was not so clear in my explanation.

I’m not trying to “convert” this document into something related to 3GPP.

However, I think what is being done there is relevant if it can be uses here as well.

What I’m saying is that it makes sense to have a single transition mechanism (if it is possible, and actually IT IS with 464XLAT) in both kind of networks.

Moreover, we need to understand that broadband deployment (residential and SMEs) in the next few years will also have 3 scenarios in order to understand the CE needs:
1) 1 or more concurrent wireline links (same or different ISPs)
2) 1 or more concurrent LTE links where wireline is not possible (same or different ISPs)
3) A mix of 2 or more concurrent wireline + LTE links (same or different ISPs).

In my opinion, considering this, again it makes a lot of sense to share a transition mechanism that can do both in the same CPE, instead of a different one for each link.

If we agree on this perspective of what is going to happen, and we agree that clearly the IPv6 deployment in 3GPP is driven by 464XLAT, there is no surprise on what I’m saying.

Despite that, I think and it has been said by real operators in this list a few months ago, they actually use RFC7048 for their RFQs to vendors, and they need support of not just 6rd and DS-lite as we have today. Some of them mention specifically lw4o6, 464XLAT and MAP.

This is why I’ve included them and personally I’ve no intend to include anything else, as I already mention. I was just asking in case I have not enough information if LISP needs to be considered, in case has more traction that what I knew. Now I guess the answer is NO.

Regards,
Jordi

-----Mensaje original-----
De: "STARK, BARBARA H" <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 12 de abril de 2017, 16:32
Para: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    > Fully agree with Cameron view, and furthermore … if we need to choose one
    > mechanism because how many millions of devices already use it, and this
    > demonstrates the success, clearly 464XLAT has more TENS OF MILLIONS of
    > users than DS-LITE + 6RD + MAP E + MAP T, altogether, and of course it
    > means a single ISP having both wired and cellular networks, can have a single
    > way to deploy IPv6 instead of two.
    
    RFC 7084 has nothing to do with cellular (3GPP) networks. 3GPP deployments are not relevant to this discussion. 3GPP and wireline deployments are not currently converged, with the 3GPP RAN and IP core networks being distinct from the wireline IP access networks (wireline is used as backhaul for the 3GPP networks at layers 1 and 2, but not for IP). What makes sense for a 3GPP deployment may or may not make sense for a wireline deployment -- especially considering the lack of extensive IA_PD support in deployed 3GPP networks.
    
    If some ISP with wireline and wireless has interest in converging their wireline IPv6 deployment with their wireless, in the very near future (using network elements that are already being trialed or have been deployed), it would indeed be nice for them to speak up. Personally, I have no internal requests from my company to drive such IPv6 convergence.
    
    So please don't use statistics related to 3GPP deployments in an argument for wireline CE routers. And please don't try to bloat the CE router with everything needed to support attachment to a 3GPP network.
    
    In the wireline deployments I'm aware of, the only ones reaching into the millions have used dual stack, 6rd, or (possibly) DS-Lite. And of these 3, the only one that I believe should ever be considered mandatory for all CE routers is dual stack.
    Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Apr 2017 14:32:33 +0000

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 17:27:09 +0200

Hi Ole,

[Jordi] I don’t agree. Several service providers have said so in the list. Some of them are big ones (I recall DT), other smaller and medium ones.

Regards,
Jordi

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Apr 2017 18:07:39 +0200 (CEST)

On Wed, 12 Apr 2017, STARK, BARBARA H wrote:

> In the wireline deployments I'm aware of, the only ones reaching into 
> the millions have used dual stack, 6rd, or (possibly) DS-Lite. And of 
> these 3, the only one that I believe should ever be considered mandatory 
> for all CE routers is dual stack.

https://stats.labs.apnic.net/ipv6/DE

I have been told that KABELDEUTSCHLAND and other DOCSIS providers in 
Germany use ds.lite. Considering the "samples" numbers, I'd say DS.lite is 
in the million+ in Germany alone.

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Apr 2017 10:10:40 -0700

> On Apr 12, 2017, at 6:12 AM, [email-masked] wrote:
> 
> Hi Barbara, 
> 

The tricky bit tends to be in how we label the update. If it "obsoletes" or "updates" 7084, we mean that any reference to 7084 becomes a reference to the new thing, or 7084 plus the new thing. We would need to clearly label it so that a procurement could reference 7084 without it, or reference 7084 and the new thing separately.

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Apr 2017 10:22:14 -0700

> On Apr 12, 2017, at 5:52 AM, STARK, BARBARA H <[email-masked]> wrote:
> 

No hats

I'm not sure I would go so far as your respective statements, but I agree that we don't want a laundry list of mechanisms that mostly make equipment more expensive, harder to use, and harder to sell. It's kind of pointless. It seems to me that if a network wants to use a given transition technology, it should specify that to its vendor(s) in the RFP/RFQ.

A data point of interest: https://ccdcoe.org/multimedia/hedgehog-fog-creating-and-detecting-ipv6-transition-mechanism-based-information.html is being flagged in the media as a reason to not deploy IPv6 - transition technologies that use tunnels apparently bypass intrusion detection technologies. I would argue that the point is flawed; put the tunnel intrusion detection technology between the tunnel endpoints and the user, problem solved. One issue there might be with the IDS itself - if it only looks at IPv4, it's not going to detect much in IPv6.

But in general, I tend to think that a better recommendation would be to walk through our list of technologies and obsolete them - like we did with 6to4.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 19:31:33 +0200

I’m not sure to understand the problem here.

The transition mechanism in this document aren’t a “MUST” (same in the actual RFC7084), so if an ISP is using this document as a reference for an RFQ, and don’t need the transition mechanism, nothing change. If the ISP want to ask in the RFQ the transition mechanism they should reference to the RFC and add a MUST for those technologies that he is going to use for the deployment, or even say something generic such as “all the transition mechanism in this RFC MUST be supported if you intend to be our provider, in addition to …. (specific vendor requirements here)”.

Obsoleting and updating, will in any case have a reference such as “this document has been obsoleted or updated by …”, either in the header or in the document itself?

I think it makes more sense obsoleting if we still have the same view of “doing updated” to the current text, instead of working in two documents as I asked in my presentation (slide 8) in Chicago. Just to remind it, the alternative was:
- Downgrade actual RFC7084 so it doesn’t include any transition mechanism and have a new document with the transition mechanisms.

We could also add some more detailed text over-explaining that the main scope of the document is IPv6-only, and the transition mechanisms as there only for the initial phase of the IPv6 deployment while there is still a need to support access to IPv4-only devices/apps in the LAN or in the “remote-IPv4-only” Internet. I think it is already clear in the actual text but we can “stress” it a bit more …

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 19:44:03 +0200

No hats
    
    I'm not sure I would go so far as your respective statements, but I agree that we don't want a laundry list of mechanisms that mostly make equipment more expensive, harder to use, and harder to sell. It's kind of pointless. It seems to me that if a network wants to use a given transition technology, it 

[Jordi] I disagree here. Adding the actual transition mechanism (all them) in the v-01 of the document (submitted today) means 0,15% of extra flash memory (slide 4 in my Chicago presentation) in the average “very low cost” CE today available in the market (8 Mbytes flash, leaving still about 2.5-3 Mbytes for future upgrades). I’ve done this analysis based on OpenWRT and several products in the market that use this or similar Linux-based implementations, which I think is probably 80% of the market today, and going up. More and more product now start using 16 Mbytes flash. There is no need for more CPU power or more RAM. In fact, there were 3 “major well-know” vendors in the meeting room and didn’t said that I’m wrong on this. May be if they are reading, they could confirm.

should specify that to its vendor(s) in the RFP/RFQ.

[Jordi] The point here is what I’ve indicated several times. Vendors are telling ISPs that they don’t support a given transition mechanism such as lw4o6, 464XLAT or MAP, because they’re aren’t in the RFC7084. Smaller ISPs have even a worst situation because they can’t do RFQs as their quantity is too small, so they just go to retail. This has been confirmed in the list by several folks.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Apr 2017 17:44:56 +0000

> What I’m saying is that it makes sense to have a single transition mechanism
> (if it is possible, and actually IT IS with 464XLAT) in both kind of networks.

464XLAT is not useful to me. It is not used in any of the networks of my employer. Therefore, it will not be requested in any RFP that I help author, nor will it be required (MUST) by any document referenced by an RFP that I help author. If it magically appears in CE routers without getting in my way, then I won't mind it being there.

-------- snip -----------

> Despite that, I think and it has been said by real operators in this list a few
> months ago, they actually use RFC7048 for their RFQs to vendors, and they
> need support of not just 6rd and DS-lite as we have today. Some of them
> mention specifically lw4o6, 464XLAT and MAP.

RFC 7084 is a mandatory requirement of BBF TR-124, which my company uses for its RFPs. Since my RFPs will not ever require (MUST) 464XLAT, if 7084-bis were to make it a MUST requirement, then 7084-bis would be useless to me as a reference and I would have to ensure 7084-bis was not a requirement in TR-124. And as someone who's written a lot of CE router RFPs, I know for a fact that it is not at all difficult to say "Req1: Do all mandatory requirements of RFC 7084-bis." "Req2: Do 464XLAT as described in RFC 7084-bis."

To be clear: I do not object to the current language of "SHOULD" for 464XLAT. I object to the proposal that it become "MUST".
While I'm at it, I also object to the current language that "If 6rd is implemented, 6in4 MUST be supported as well."  This statement will make the document useless for me as a RFP reference (directly or indirectly), because I will not be requiring 6in4 in my CE routers.

If you want IETF to produce a CE router profile that is just intended to be useful for some operators, please don't call it 7084-bis or have it obsolete 7084. Make it something else (not 7084-bis). A 7084-bis that mandates (MUST) any particular transition technology other than the one deployed in my network is unacceptable to me. And that includes mandating a technology not deployed in my network, just because it implements one that is deployed.

For this document to be a true replacement of RFC 7084, it MUST NOT introduce any "MUST" requirements that an operator currently using RFC 7084 (directly or indirectly) does not want in their CE router.
7084-bis MUST NOT interfere with, place undue burden on, or add cost to existing deployments and the CE routers used in those existing deployments.
Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 19:52:38 +0200

Hi Barbara,

Thanks a lot for the explanation. I see your point clearer now.

I’ve never intended (once I made the first question on this in the list and got some inputs, before the first individual ID version), to use MUST.

I used MUST for the 6in4 if 6rd is available, because when you have 6rd support in any router, you can just select 6rd and configure a 6in4 and it works, but many ISPs don’t even realize it because they can’t see “a menu” (if using the GUI, just an example), 6in4. So, my intent was to make it more “obvious”.

If you feel that using the work MUST “breaks” it, I will find an alternative way to explain it and keep using MAY in this case.

Ii think we will be in-sync with that change, unless you spot anything else in the current version … of course happy to heard about that!

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 20:02:41 +0200

May be this will make it:

Actual text:
The CE router MAY support 6in4 functionality.  If 6rd is implemented,
6in4 MUST be supported as well.

New text:
The CE router MAY support 6in4 functionality.  If 6rd is implemented,
6in4 is already supported as well, as the underlying protocol/technology 
is the same, being the only difference, having the mention of “6in4” 
in the GUI/CLI (just an example) if it is being configured manually,
or even stating that in the relevant documentation. In other words, 
no additional code is required for the support of 6in4 when 6rd is already supported

Saludos,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de JORDI PALET MARTINEZ <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 12 de abril de 2017, 19:52
Para: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    Hi Barbara,

    

    
    Regards,
    Jordi

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Apr 2017 11:24:41 -0700

> On Apr 12, 2017, at 10:44 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> [Jordi] I disagree here. Adding the actual transition mechanism (all them) in the v-01 of the document (submitted today) means 0,15% of extra flash memory 

no hats

Perhaps true. It also means that the vendor (open source is a vendor, from this perspective) allocates human resources, which cost money, to write and maintain the software. The software has some probability of bugs per volume of code, which means that there is a quantifiable security risk. Now, any business calculates its costs and potential upside benefits, and figures out how to make money (even open source developers do, believe me). Asking them to spend money with little real opportunity to gain saddles them with a cost and a risk with little upside. It's not the volume and price of the flash; it's the support costs.

If the vendor is looking at 7084 for guidance and saying there is no market for a given technology, it's because the operators in this working group collectively said there was no market in their networks. In the end it isn't about an RFC, it's about a market. No market, no money, no product. It's that simple.

If I'm hearing anything in this discussion, it's that the end game isn't found in having all of the transition technologies in product. It's to be found in native deployment that doesn't need the transition technologies.

You might find these two links interesting. One is from the IPv4 Market Group, and makes prognostications on the value of an IPv4 address; the other is a public presentation by Swisscom about the traffic measurements in its network. In both cases, they are asking when they expect IPv6 usage, whether in traffic or in users, to exceed IPv4, and as a result when the need for dual stack deployment starts to wind down. Both, by different avenues, pick 2019 as the turning point, and Swisscom suggests that by 2024 it might not have enough IPv4 traffic in its network to justify having IPv4 enabled - even in an overlay.

The issue of transition mechanisms has to do with networks being predominantly IPv4 and having to reach them using IPv6. Both are saying that there is a light at the end of that particular tunnel, and it's not an oncoming train.

http://ipv4marketgroup.com/q42016-update/
http://www.ipv6conference.ch/wp-content/uploads/2015/06/B10-Swisscom-Status_Roadmap_and_Outlook_IPv6.pdf

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 20:52:37 +0200

no hats

[Jordi] Not really that much cost:
- Code is available in source, actually there are several implementations.
- Vendor can choose one source, integrate it with his own code (being linux should not be more than a couple of hours).
- Code has been tested already, so yes, still some “integration testing”, again should not be a big issue.
- Yes, more code more bugs, but if it is Linux, it is somehow “self-maintained” from the “source”.

⇒ What I know from several vendors of those CPEs that I’ve talked to, is that they basically take the code of OpenWRT (or others), and personalize the drivers for different chipsets and the GUI. So, adding something that is already done by the community is not the problem at all.

[Jordi] I think is working in both ways. Vendors look at RFC7084 and integrate their boxes. ISPs talk to vendors and use the RFC7084 to push vendors. But if vendors don’t have a push for a specific technology, because ISPs get an “initial” “isn’t in the RFC7084”, then it never gets done. Also, once a couple of “big” retail (which are the same as ISP CE, but sometime OEM branded) vendors have support for the “new” transition mechs, the others need to do the same, just a matter of competition. Right now, there are 2-3 vendors, but they are expensive and they don’t even consider orders for 10.000 units or are too expensive for many markets. I tried it with several of them … working for customers. Also, I understand that most of the vendors could update the actual products in the market with new firmware, but they don’t do that, because it is better to sell new products to the same ISPs … That’s why I’ve been forced to use in several trials OpenWRT, and also a couple of ISPs actually using it for commercial deployment, reflashing existing “retail” products.

[Jordi] Fully agree, but today you can’t tell any ISP that you’re going to deliver IPv6 only CPEs, because customers will not need to access any IPv4 resource in remote Internet or even in their own local networks. Any ISP trying to sell “IPv6-only in the LAN and in the WAN” services, will lose 99% of his customers.

    

[Jordi] I already knew the 2nd one, however is a bit older (mid-2015) so I believe the picture changed a lot, and there is much more IPv6 traffic and I’m even more optimistic that it will be predomintanly-IPv6 sooner than any expectation, but still customers will not throw away their local IPv4-only devices (cameras, smartTVs, etc.), and there will be at least 4-5 more years with a considerable amount of IPv4-only sites. Probably 2020-21 it may be possible to start considering disabling IPv4 traffic (in my opinion) but still think that the support of IPv4-only local devices may take a longer time. How you convince folks to buy a new smartTV in 4-5 years, that they have purchased today (at least in Spain they still come w/o IPv6 support), unless the vendor upgrades the firmware? What about all kind of devices (IP cameras, wifi doorbell, cleaning robot, etc.), that today come with IPv4-only ? I think we may see LAN-IPv4 traffic for a longer period, unfortunately, and this is the reason the CPE must support it and some of those “traffic-flows” may require access to IPv4 remote sites (cloud services they are based on).

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Apr 2017 18:54:58 +0000

> 6in4 is already supported as well, as the underlying protocol/technology is
> the same, being the only difference, having the mention of “6in4”
> in the GUI/CLI (just an example) if it is being configured manually, or even
> stating that in the relevant documentation. In other words, no additional
> code is required for the support of 6in4 when 6rd is already supported

No. 
I'm fine suggesting that RFC 5569 MAY be supported. 
This RFC is commonly referred to as "6rd". Anyone who wants to have RFC 5569 functionality referred to by another name in their GUI or other user interface is free to do so. UI naming, character set, and language are not in scope of this document.

RFC 5569 does not reference RFC 4213. It has no dependency on RFC 4213 and is not the same as RFC 4213. These are 2 distinct and separate RFCs.
I will not support any linkage of these 2 RFCs in a 7084-bis.
This would impact my company and the requirements we use in CE router procurement directly (making it impossible for us to use 7084-bis as a reference directly or through BBF TR-124).

If there's someone who wants RFC 4213, let them justify it without trying to add expense and complexity to my CE routers.
Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Apr 2017 21:01:46 +0200

Hi Barbara,

RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is referring to RFC2893 (6in4, protocol 41), which has been updated by RFC4213.

We are talking about the same.

If you have a 6to4 router at home, you can just try. Create a HE tunnel broker, and input manually the parameters even if your router only shows a 6rd in the GUI. It works. Believe me.

Regards,
Jordi

-----Mensaje original-----
De: "STARK, BARBARA H" <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 12 de abril de 2017, 20:54
Para: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    No.

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Apr 2017 12:23:17 -0700

> On Apr 12, 2017, at 11:54 AM, STARK, BARBARA H <[email-masked]> wrote:
> 

Aka "dual stack" and "Configured tunneling of IPv6 over IPv4", in the words of the RFC.

https://tools.ietf.org/html/rfc4213
4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark,
     R. Gilligan. October 2005. (Format: TXT=58575 bytes) (Obsoletes
     RFC2893) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC4213)

I think you will find dual stack pretty widely supported. SIXXS depended on the ability to configure tunnels through their tunnel broker, and HE's tunnel broker continues to. I suspect you will find IPv6/IPv4 tunnels supported on a variety of routers. I also suspect that your IPv6-capable residential customers won't need them. For them, RFC 4213 == Dual Stack.

If I were to whine about tunnels, it would be about the routing and security issues. RFCs 6169, 6324, 7059, a recent CCDCOE article, and so on.

---

From: james woodyatt <[email-masked]>
Date: Wed, 12 Apr 2017 11:50:36 -0700

On Apr 12, 2017, at 10:22, Fred Baker <[email-masked]> wrote:
> 
> A data point of interest: https://ccdcoe.org/multimedia/hedgehog-fog-creating-and-detecting-ipv6-transition-mechanism-based-information.html <https://ccdcoe.org/multimedia/hedgehog-fog-creating-and-detecting-ipv6-transition-mechanism-based-information.html> is being flagged in the media as a reason to not deploy IPv6 - transition technologies that use tunnels apparently bypass intrusion detection technologies.

After seeing Fig 3. on p. 6 of that paper, I don’t think I can offer a sensible response to such arguments in any form other than a sarcastic quip embedded in an image macro.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: [email-masked]
Date: Wed, 12 Apr 2017 22:39:08 +0200

Jordi,

> If you have a 6to4 router at home, you can just try. Create a HE tunnel broker, and input manually the parameters even if your router only shows a 6rd in the GUI. It works. Believe me.

This is the IETF. There are other implementations than Linux.
If there wasn't you didn't need a standard.

Cheers,
Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Apr 2017 19:20:40 +0000

> RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is referring
> to RFC2893 (6in4, protocol 41), which has been updated by RFC4213.
> 
> If you have a 6to4 router at home, you can just try. Create a HE tunnel
> broker, and input manually the parameters even if your router only shows a
> 6rd in the GUI. It works. Believe me.

What I think I hear you saying is:
If a CE router implements RFC 5569, then the access network can use the CE router's RFC 5569 functionality to deliver a RFC 4213 tunnel.

If this is correct, then what I'm saying is I will not support a requirement that dictates I and my CE router vendors (who implement 6rd) MUST look at or read  or scour RFC 4213 to see if there is some additional requirement that RFC 4213 introduces, because they are now required to be compliant with it. The reference to RFC 5569 SHALL be sufficient to direct implementation of the functionality, with no reference to RFC 4213.
UI requirements are out of scope.
Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Apr 2017 10:07:43 +0200

Hi Ole,

Actually, most of the times I’ve done this they were non-Linux boxes.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 12 de abril de 2017, 22:39
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    Jordi,

    
    Cheers,
    Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 Apr 2017 10:32:39 +0200 (CEST)

On Wed, 12 Apr 2017, JORDI PALET MARTINEZ wrote:

> is the same, being the only difference, having the mention of “6in4” in 
> the GUI/CLI (just an example) if it is being configured manually, or 
> even stating that in the relevant documentation. In other words, no 
> additional code is required for the support of 6in4 when 6rd is already 
> supported

In the original 6RD-2 requirement that talks about user configuration, for 
configuring 6in4 the UI would need to look slightly different, right? 
Depending on some choices in UI, some input methods of the parameters 
might not work with 6in4.

So I guess your intention to include 6in4 could be done either as a new 
transition protocol with SHOULD, or it can add an additional MAY 
requirement in 6RD that the settings be compatible for configuring a 
generic 6in4 tunnel as well. The above text seems to be the latter?

I think it would actually make more sense to create a "new" transition 
technology in there in that case. That would keep it clean the way I 
interpret Barbaras intention is?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Apr 2017 11:05:10 +0200

Hi Mikael,

No, it is actually much easier than that. The text I proposes will go to the same section (6in4). So, it will be (for the sake of clarity):

5.4.2.  6in4

   6in4 [RFC4213] specifies a tunneling mechanism to allow end-users to
   manually configure IPv6 support via a service provider's IPv4 network
   infrastructure.

   The CE router MAY support 6in4 functionality.  If 6rd is implemented,
   6in4 is already supported as well, as the underlying protocol/technology
   is the same, being the only difference, having the mention of “6in4” in
   the GUI/CLI (just an example) if it is being configured manually, or
   even stating that in the relevant documentation. In other words, no
   additional code is required for the support of 6in4 when 6rd is already
   supported. If 6in4 is supported, it MUST be implemented according to 
   [RFC4213].  The following CE Requirements also apply:

…

No code is required at all, and in any case, the target is MAY, same as we have it right now also for 6rd. Let me explain.

Let’s suppose you have *any* router or OS with 6rd support, never mind the configuration is done by means of DHCP or user-entered configuration (as you said original 6RD-2, but also 6RD-1 and 6RD-3), and instead of a 6RD relay, you provide the 6in4 tunnel-end-point, it just works.

It is simple to understand, because both, 6in4, 6to4, and 6rd, actually do exactly the same encapsulation/decapsulation (protocol-41), and exactly the same routing thing. The difference is that in 6in4 is called a tunnel broker (or similar), in 6to4 is a 6to4 relay, etc. All the parameters in the UI are the same.

What it means from the perspective of the CE implementer: only a minor text change in the UI. The UI today has a “menu” to allow 6RD-2 config, that says “6rd”. What I’m saying is it to be changed to say “6rd/6in4” or alternatively, one option for “6rd” and another for “6in4”, but actually both choices will bring to the same “code”.

I believe Barbara is worried that if I keep it as a different than 6rd transition mechanism (as it is actually in the current -01 version, see section 5.4.2), because I’m referring to RFC4213, I’m “adding” more requirements behind that RFC. I’m actually reading all those documents and I believe she is wrong on that, but I will answer that in a few minutes.

I see no “technical” difference in having it as part of the 6rd text or as it is right now a separated one, which seems to me (I think you agree on this, if I understood correctly) your email, clearer.

Regards,
Jordi

---

From: [email-masked]
Date: Thu, 13 Apr 2017 11:22:41 +0200

Jordi,

Where have you got the idea that an implementation of 6RD also supports Configured tunnels?
That is wrong.

Ole

> On 13 Apr 2017, at 11:05, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Mikael,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Apr 2017 11:27:23 +0200

Believe me, just try it.

I’ve tried this with many CEs that had a “6rd” choice and NO “6in4”. If you use the configured tunnel end-point parameters to “lie” to the CE, it just works. And this is normal if you look into the details of how 6to4, 6in4 configured tunnels and 6rd work. They do the same, the difference is at the “provider edge”.

The CE don’t “see” any difference between them.

In fact I’ve many customers using it, both residential and SMEs.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 13 de abril de 2017, 11:22
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    Jordi,

    Ole

---

From: [email-masked]
Date: Thu, 13 Apr 2017 11:44:15 +0200

Jordi,

> Believe me, just try it.

Oh geez... You seem completely stuck with the implementations (Linux based) that you have tried.

> In fact I’ve many customers using it, both residential and SMEs.

Take VPP for example. Does not behave like you think every implementation does:
https://git.fd.io/vpp/tree/src/plugins/sixrd

Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Apr 2017 11:57:47 +0200

No Ole, actually I don’t think I’ve tried it with Linux, just with regular CEs, both from retail and provided by ISPs.

There is no way the CE knows if the tunnel-end-point is a 6rd or a 6in4 or a 6to4, and looking at your link it seems the same to me … may be you can point exactly to what source line/section you think will “break it”?

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 13 de abril de 2017, 11:44
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    Jordi,

    

    Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 Apr 2017 12:33:37 +0200 (CEST)

On Thu, 13 Apr 2017, JORDI PALET MARTINEZ wrote:

> It is simple to understand, because both, 6in4, 6to4, and 6rd, actually 
> do exactly the same encapsulation/decapsulation (protocol-41), and 
> exactly the same routing thing. The difference is that in 6in4 is called 
> a tunnel broker (or similar), in 6to4 is a 6to4 relay, etc. All the 
> parameters in the UI are the same.

Not necessarily. For 6to4, you basically don't need any user settable 
parameters. It's all well-known. For 6in4, you need delegated prefix, 
remote IPv4 relay address. For 6RD you need even more parameters, 
especially for the modes where you don't map everything into the full IPv4 
32 bit space.

So the UI designer need to take into account all these three, or the user 
will probably be confused. Yes, 6in4 and 6to4 are subsets of 6RD but they 
still require different code to do the UI and input validation correctly, 
compared to 6RD. My opinion is that your text should be changed to 
something like this to paint the minor difference in a more positive 
light?

----

The CE router MAY support 6in4 functionality.  The main difference between 
6in4 and 6rd is the parameters needed for configuration. The on-wire and 
forwarding plane is identical for both mechanisms. Thus, if the device 
supports either 6rd or 6in4, it's commonly a minor UI addition to support 
both.  If 6in4 is supported, it MUST be implemented according to 
[RFC4213].  The following CE Requirements also apply:

---

I am not really happy about above text, I'm sure someone can rewrite it 
even better.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 18 Apr 2017 09:36:44 +0200

* [email-masked]

> You are proposing to carry that failure forward and require all CE
> implementations to implement _all_ the mechanisms in existence?
> 

+1

> If I remember correctly that list is now: RFC2473, GRE, L2TP, LISP,
> MAP-E, MAP-T, 4RD, 464XLAT, Public 4over6, LW46, Dynamic LW46, ...

Yup.

Almost half of the requirements section in this document named «*Basic*
Requirements for *IPv6* Customer Edge Routers» (emphasis mine) is
talking about this plethora of *IPv4* stuff. It is getting ridiculous.

IMO: Nuke section 5.4 completely. Relegate the list of all current
«transitioning off IPv4» technologies to a short appendix containing
informative references. Let the individual ISPs specify which of those
technologies, if any, is a MUST for CE routers to be deployed in their
specific networks.

Tore