Subject: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 04 Nov 2016 18:32:10 +0100

Right sorry, write down the old reference (I was actually referring to the 7084), corrected also in the subject

Regards,
Jordi

-----Mensaje original-----
De: krunal shah <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 4 de noviembre de 2016, 18:19
Para: <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] do we need to update RFC6204 ? - Basic Requirements for IPv6 Customer Edge Routers

    RFC 7084 <https://tools.ietf.org/html/rfc7084> Basic Requirements for IPv6 Customer Edge Routers
    
    Krunal

    On Fri, Nov 4, 2016 at 12:20 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:
    
    When this document was published, the IPv4 situation was different that the actual one.
    
    Many ISPs could have deployed IPv6 using dual stack, or 6rd.
    
    Also, lw6over4 was not available, same as other protocols such as MAP, or 464XLAT, or there was no sufficient experience with them.
    
    Now the situation is totally different, and ISPs will need to provide IPv6 service-only in the access link, instead of 6in4 based mechanisms, unless they opt for dual-stack with CGN.
    
    So my question is: should this document be updated to reflect the new situation, so to provide a better guidance to both the ISPs and the vendors?
    
    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.

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

    

**********************************************
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: Alejandro D'Egidio <[email-masked]>
Date: Fri, 4 Nov 2016 15:07:36 -0300 (ART)

Hello,
  I think this is intereseting.
  I work in a MSO and personally, I've been requesting support for 464XLAT (CLAT) in CableModem to many vendors without success.
  This feature is already implemented in openWrt and I think it's a very good option. For example, in our case we have depleted our public IPv4. Because of that, we had to implement a CGN. If now we already have a CGN with support of 464XLAT it would be great if we don't provide reserved IPv4 any more to our CPEs, just IPv6.
  So, why not include it as a basic requirement for IPv6 CPEs?

Thanks and Regards

Alejandro D'Egidio 
Jefe de Ingeniería de Backbone 
[ mailto:[email-masked] | [email-masked] ] 

Lavardén 157 | Tel: 54 11 3977 1025 
C1437FBC | CABA | Argentina 
TELECENTRO S.A. 

ESTE MENSAJE ES CONFIDENCIAL. Puede contener información amparada por el secreto profesional. Si usted ha recibido este e-mail por error, por favor comuníquenoslo inmediatamente vía e-mail y tenga la amabilidad de eliminarlo de su sistema; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. 

THIS MESSAGE IS CONFIDENTIAL. It may also contain information that is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by e-mail immediately and delete it from your system; should also not copy the message nor disclose its contents to anyone. Many thanks.

----- Mensaje original -----
De: "JORDI PALET MARTINEZ" <[email-masked]>
Para: "krun shah" <[email-masked]>
CC: [email-masked]
Enviados: Viernes, 4 de Noviembre 2016 14:32:10
Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

Regards,
Jordi

-----Mensaje original-----
De: krunal shah <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 4 de noviembre de 2016, 18:19
Para: <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [v6ops] do we need to update RFC6204 ? - Basic Requirements for IPv6 Customer Edge Routers

    Krunal

    

    
    
    Regards,
    Jordi

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 4 Nov 2016 19:09:23 +0000

>     Also, lw6over4 was not available, same as other protocols such as MAP, or
> 464XLAT, or there was no sufficient experience with them.
> 
>     Now the situation is totally different, and ISPs will need to provide IPv6
> service-only in the access link, instead of 6in4 based mechanisms, unless they
> opt for dual-stack with CGN.
> 
>     So my question is: should this document be updated to reflect the new
> situation, so to provide a better guidance to both the ISPs and the vendors?

RFC 7084 was never intended as advice to ISPs. It was intended as advice from ISPs to vendors of retail CE Routers. Along the lines of:
Given IPv6 access network architectures ISPs have documented in CableLabs and Broadband Forum (BBF), here is a set of common requirements for a retail CE Router that can be used to connect to either of those types of access networks.

If there is more than one ISP who is seriously committed to deploying one of the technologies you list (not just studying or thinking about it), and they want to extend RFC 7084, they should come forward. But I don't think it should be extended for any technology that doesn't have a real deployment commitment from multiple providers. I was very disappointed that some European ISPs pushed really hard to get DS Lite documented in BBF and RFC 7084, and then did nothing with that technology. CE Router vendors should not be asked to expend their scarce resources in support of experimental technologies. Experiments can be done with OpenWRT types of firmware. RFC 7084 extension needs to be done only for widely deployed technologies.

BTW, we also stayed away from 3GPP access architectures, because there was no participation from 3GPP ISPs. The ISPs doing widespread deployment must be involved in providing the advice.
Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 04 Nov 2016 20:18:42 +0100

This is happening already, one of those ISPs sent already a message to the list some minutes ago.

464XLAT is being deployed in both wired/residential networks and also cellular ones.

The only reason is not happening more is precisely because there are very few vendors offering it. I think only Nec and Yamaha, if I recall correctly.

I know the topic very well because I’m working in several of those deployments.

So I will be very happy to contribute to it or even take over that work if the original authors aren’t interested.

There are already many deployments using 464XLAT in cellular phones, and some people has the same issues trying to deploy LTE modems/routers where the wired network can’t reach, so I think this should also be included in this work.

Regards,
Jordi

---

From: Erik Kline <[email-masked]>
Date: Fri, 4 Nov 2016 15:50:12 -0400

It does seem like the transition models are basically boiling down to
two: dualstack and IPv6-only+NAT64/DNS64.

I wouldn't refer to the latter as "464xlat" because I read that as
actually specifying the client behaviour.  The customer/clients could
instead be perfectly happy being IPv6-only on such a network (a la iOS
devices).

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 04 Nov 2016 20:58:08 +0100

There are two ways of doing that:

1) Having control of the “apps” so they are supporting IPv6 (the way Apple is doing), so you just need (in this case) IPv6-only+NAT64/DNS64.
2) Not having that control (which is what happens mainly in wired networks, because instead of cellular phones you have all kind of IPv4 only devices/apps, including those that still use literal IPv4 addresses, older libraries, etc.), or venders such as Android or Windows that at the time being don’t mandate the IPv6 support in the apps. In this case you need the CLAT part added to the IPv6-only+NAT64/DNS64.

My view is that if we update the document, actually 1 is already “under” control, means nothing to be done in the device itself, is a vendor decision to impose to their app developers. But 2 needs to be explicitly stated as a requirement.

Regards,
Jordi

---

From: Tore Anderson <[email-masked]>
Date: Fri, 4 Nov 2016 21:00:12 +0100

* JORDI PALET MARTINEZ

> The only reason is not happening more is precisely because there are
> very few vendors offering it. I think only Nec and Yamaha, if I
> recall correctly.
> 
> So I will be very happy to contribute to it or even take over that
> work if the original authors aren’t interested.
> 
> There are already many deployments using 464XLAT in cellular phones,
> and some people has the same issues trying to deploy LTE
> modems/routers where the wired network can’t reach, so I think this
> should also be included in this work.

IMHO the entire section 4.4 would best be left out of a 7084bis.

464XLAT and DS-Lite are not technologies that bring IPv6 connectivity.
They bring IPv4 connectivity. It doesn't make any sense for a document
that «specifies requirements for an IPv6 Customer Edge (CE) router» to
mandate support for any such technology. We have the market for that.

Tore

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 4 Nov 2016 21:06:52 +0000

I somewhat agree with Tore. 

5-10yrs from now, maintaining IPv4 connectivity may not be required (for many, if not all). So, why infuse that in a document that is all about IPv6.

-- 
Cheers,
Rajiv

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 04 Nov 2016 22:12:28 +0100

The abstract explicitly states: The document also covers IP transition technologies.

Also in the intro: These routers typically also support IPv4.

And it clearly makes sense, is real life today, because we like it or not, we can’t switch off IPv4 day-night, so for some years, we need to provide support for existing IPv4 devices in the internal networks.

The market is not necessarily doing the right thing if IETF is not there helping with some guidance. And in fact this situation is a clear example: We asked support for 6rd and DS-Lite, and it is there in many vendors, but those mechanisms are no longer the “best” choices, and as we didn’t explicitly asked support for newer (IPv6-only mechanisms), they are not there, while the ISPs require it.

An alternative is to have an IPv6-only CE requirements document.

Regards,
Jordi

-----Mensaje original-----
De: Tore Anderson <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 4 de noviembre de 2016, 21:00
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

    * JORDI PALET MARTINEZ

    
    
    Tore

---

From: Sander Steffann <[email-masked]>
Date: Fri, 4 Nov 2016 22:16:42 +0100

Hi Barbara,

> I was very disappointed that some European ISPs pushed really hard to get DS Lite documented in BBF and RFC 7084, and then did nothing with that technology.

Speaking as a customer of such a European ISP I can confirm that DS-Lite is very much used here. I am currently behind

DS-Lite-FQDN:  aftr01.upc.nl
DS-Lite-adres: 2001:730:2000:2::31

At least in the Netherlands DS-Lite has been deployed to hundreds of thousands of users already, and the numbers are still going up. I think that ISPs did nothing with DS-Lite is a misconception.

Cheers,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Nov 2016 22:58:50 +0100 (CET)

On Fri, 4 Nov 2016, Sander Steffann wrote:

> At least in the Netherlands DS-Lite has been deployed to hundreds of 
> thousands of users already, and the numbers are still going up. I think 
> that ISPs did nothing with DS-Lite is a misconception.

All the ds.lite I know of are from Cable providers, ie DOCSIS3 
deployments.

Do you see ds.lite in any other space, ie non-cable operators?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Fri, 4 Nov 2016 23:14:32 +0100

* JORDI PALET MARTINEZ

> The abstract explicitly states: The document also covers IP

A prime candidate for deletion in a 7084bis document.

> And it clearly makes sense, is real life today, because we like it or
> not, we can’t switch off IPv4 day-night, so for some years, we need
> to provide support for existing IPv4 devices in the internal networks.

Nobody suggested making a 7084bis document prohibit IPv6 CE routers
from also supporting native IPv4 (or your favourite IPv4 transition
technology).

> The market is not necessarily doing the right thing if IETF is not
> there helping with some guidance. And in fact this situation is a
> clear example: We asked support for 6rd and DS-Lite, and it is there
> in many vendors, but those mechanisms are no longer the “best”
> choices, and as we didn’t explicitly asked support for newer
> (IPv6-only mechanisms), they are not there, while the ISPs require it.

They will be there if the ISPs ask for it. You already mentioned that
you'd found two different CPE vendors that implemented the transition
technology you wanted - so why not simply buy your CPEs from them? You
(and others) doing that is the best way to make their competitors
follow suit.

In any case, assuming you want to avoid having 7084bis require every
single one of the many transition technologies that exist, but instead
single out "best", to use your word, you first have to get consensus
on which one actually is the "best". That sounds like going down the
rathole to me.

> An alternative is to have an IPv6-only CE requirements document.

Listing the technical requirements specific to delivering IPv6 indeed
precisely what a properly focused IPV6 CE router document should
contain. Anything else, such as stating which IPv4 transition
technology is the "best", should be considered out of scope.

If the CE vendor decides to also implement support for 464XLAT it can
find perfectly fine guidance on how to go about doing that in RFC6877.
4RD? RFC7600. MAP-E? RFC7597. And so forth.

Tore

---

From: Sander Steffann <[email-masked]>
Date: Sat, 5 Nov 2016 00:09:44 +0100

Hi,

> All the ds.lite I know of are from Cable providers, ie DOCSIS3 deployments.
> 

Not yet, although I expect cases where the cable modem is put into bridged mode and then a separate CPE behind it will do DS-Lite. The cable operators that I have spoken to don't allow this yet, but it is being discussed.

Cheers,
Sander

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 05 Nov 2016 09:34:41 +0200

> Do you see ds.lite in any other space, ie non-cable operators?
We, as a fixed/DSL operator, use DS-Lite  on a large percentage of our subscribers.
Recently we started adding PCP to the mix.

--
Tassos

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 05 Nov 2016 10:54:31 +0100

I’ve also some trials with DSL customers, thousands of users each trial.

Some of those trials have been running for a couple of years already, and the reason not to go into commercial is precisely because they will prefer to use the same transition mechanism in all the network (they are using 464XLAT in the cellular trial), but the vendors aren’t supporting it and one of the arguments is not suggested as a requirement from the IETF ...

Also looking at the recent IPv6 survey I can see the following stats:
1) 5 LTE/router deployments with dual stack - CGN (private IPv4, global IPv6).
2) 2 LTE/router deployments with dual stack (public IPv4, global IPv6).
3) 1 LTE/router deployment with DS-Lite.
4) 2 LTE/router deployment with tunnel broker.
5) 1 Cable deployment with 464XLAT.
6) 2 Cable deployments with 6to4.
7) 2 Cable deployments with dual stack - CGN (private IPv4, global IPv6)
8) 2 Cable deployments with DS-Lite.
9) 42 Cable deployments with dual stack (public IPv4, global IPv6)
10) 1 Cable deployment with lw4o6.
11) 1 Cable deployment with MAP-T.
12) 2 Cable deployments with tunnel broker.
13) 5 FTTH deployments with 464XLAT.
14) 2 FTTH deployments with 6RD.
15) 8 FTTH deployments with 6to4.
16) 7 FTTH deployments with dual stack - CGN (private IPv4, global IPv6).
17) 4 FTTH deployments with DS-Lite.
18) 93 FTTH deployments with dual stack (public IPv4, global IPv6).
19) 1 FTTH deployment with MAP-E.
20) 1 FTTH deployment with tunnel broker.
21) 4 xDSL deployments with dual stack - CGN (private IPv4, global IPv6).
22) 7 xDSL deployments with DS-Lite.
23) 71 xDSL deployments with dual stack (public IPv4, global IPv6).
24) 9 xDSL deployments with 6RD.
25) 3 xDSL deployments with 464XLAT.
26) 2 xDSL deployments with tunnel broker.
27) 1 xDSL deployment using softwires (L2TP).
28) 6 Wireless (LMDS, WiFi, WiMax, etc.) deployments with dual stack - CGN (private IPv4, global IPv6).
29) 22 Wireless (LMDS, WiFi, WiMax, etc.) deployments with dual stack (public IPv4, global IPv6).
30) 1 Wireless (LMDS, WiFi, WiMax, etc.) deployment with 464XLAT.

In addition to all that, there are some other access technologies being used, with different transition mechanisms.

By the way, most of the 464XLAT deployments are done using OpenWRT, taking advantage of existing CPEs that can be reflashed, because lack of support from the original vendors.

The survey got already 1.223 responses up to now. I’m providing here only the numbers for those that responded with specific details about the transition technology. There are many other answers with have left this empty, probably customers that don’t know. In general, more complete responses come from the ISP employees, which also provide the contact details, and I talked with them in some cases to clarify specific answers to the survey.

I did a recent presentation at the last RIPE meeting (not going into so many detailed data as here)
Slides - https://ripe73.ripe.net/presentations/22-IPv6-survey-October-2016.pdf
Video - https://ripe73.ripe.net/archives/video/1242/

Survey available here, if you still haven’t answered it or something changed in your network:
http://survey.consulintel.es/index.php/175122

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Tassos Chatzithomaoglou <[email-masked]>
Responder a: <[email-masked]>
Fecha: sábado, 5 de noviembre de 2016, 8:34
Para: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

    --
    Tassos

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 05 Nov 2016 11:22:28 +0100

Below in-line.

-----Mensaje original-----
De: Tore Anderson <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 4 de noviembre de 2016, 23:14
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

    * JORDI PALET MARTINEZ

  
⇒ There is a lot of text about IPv4, I just started with the 1st 2 pages …

    
-> If the document is meant for dual stack support as in today world, then we need to have it more complete with “actual” transition technologies. 6RD is no longer meaningful in a world where ISPs will not have sufficient public IPv4 addresses for all the customers. The same as the actual document talks about DS-LITE, should mention updated technologies. Otherwise we need two documents, one for IPv6-only CPEs, one for CPEs that still need to support IPv4.

    
⇒ Believe me, is not that way. Unless you have a strong purchasing power, small ISPs (and there are many with just a few hundreds or thousands of customers), vendors will not update their code for you, even if that’s pretty easy to do. And even more, sometimes vendors provide firmware updated to existing hardware if is not too old, but they don’t support new transition mechanism because a small ISP ask for it. Look for example at Mikrotik, I’ve many customers using this and they don’t have support for 6rd, DS-LITE, NAT64, 464LAT, Sofwires, etc. It is true that Mikrotik is more used as a corporate (SME) CPE, but also in many Wireless deployments (for reaching remote residential customers). However, if you look to the “major” CPE vendors for all the access technologies (Technicolor, Arris, Linksys, Comtrend, Asus, AVM, Belkin, Buffalo, D-link, Huawei, Netgear, TP-Link, Trendnet, ZTE, Zyxel and so and so), most of them have implemented only 6RD and DS-LITE, because that’s what we have in this document! So they really follow it.

⇒ We can workout a text that explain different scenarios and possible mechanisms for each of them. There is no need to say all them must be supported, but a recommendation. After all, the code to support most of them is 1) open source 2) very compact 3) some times even shared code. What it means is that if a vendor want to support several of them, is possible in most of the devices that already support dual-stack, 6rd, ds-lite.  Basics are almost the same.

    
   
⇒ Look at what is being actually implemented: 6rd and DS-lite, just what we have at this document.
 
    Tore

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 05 Nov 2016 12:10:23 +0100

By the way, forgot something with is quite relevant.

Yes, there are a couple of vendors that officially support 464XLAT, but if you try compare the pricing with other low cost CPEs which are the ones used in most of the ISP networks for residential customer, there is a big gap. Small ISPs can’t use them, they have a low volume, even sometimes, they buy indirectly and not from the makers but from local market, and even sometimes, the end-user is responsible for buying a new CPE, etc. So if the support is not widely available in almost each low cost CPE (in addition to more expensive ones), transition is not going to happen in the best way and it will take much longer.

As a standards community, I don’t think this is what we want. Neither I think is what ISPs wish.

Oh yeah, this is what vendor prefer, selling now one CPE, and tomorrow another one … but I don’t think our mission here is to help them to make profit, but to make better products that have a longer lifetime. Product that can be used in today networks, but still work in tomorrow ones, when the ISPs only want to provide IPv6-only WAN links, because they can’t do IPv4 anymore, and they want to avoid CGN as much as possible, the CPE is still able to do that, instead of going to one more replacement cycle.

Regards,
Jordi

-----Mensaje original-----
De: JORDI PALET MARTINEZ <[email-masked]>
Fecha: sábado, 5 de noviembre de 2016, 11:22
Para: <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

    Below in-line.
    
    -----Mensaje original-----
    De: Tore Anderson <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: viernes, 4 de noviembre de 2016, 23:14
    Para: JORDI PALET MARTINEZ <[email-masked]>
    CC: "[email-masked]" <[email-masked]>
    Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers
    
        * JORDI PALET MARTINEZ

      

        

        

       

       
     
        Tore

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 5 Nov 2016 11:36:57 +0000

Jordi,

I agree to your reasoning. I wish 7084 focused on only v6 requirements and there was another document that focused on v4 overlay (and whatever else) requirements in a separate document. Perhaps, we have an opportunity to do that now.

Taking a long-term view (5-10yr out), such a separation would be useful for vendors to not bloat with unwanted features that won't be useful to every ISP.

Of course, that's not to say that those features such as 464XLAT, MAP-T/E etc. are not useful at the moment.

One minor clarification,

but still work in tomorrow ones, when the ISPs only want to provide IPv6-only WAN links, because they can’t do IPv4 anymore, and they want to avoid CGN as much as possible, the CPE is still able to do that,

CGN could be intended for stateful NAT44 or stateful NAT64, key is that it lives in the ISP network.

With 464XLAT, CGN64 is needed.

If the intent in the above statement is to avoid stateful CGN altogether, then MAP-T/E is the way to go.

Cheers,
Rajiv

On Nov 5, 2016, at 7:10 AM, JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Jordi

-----Mensaje original-----
De: JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>>
Fecha: sábado, 5 de noviembre de 2016, 11:22
Para: <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

   Below in-line.

   -----Mensaje original-----
   De: Tore Anderson <[email-masked]<mailto:[email-masked]>>
   Responder a: <[email-masked]<mailto:[email-masked]>>
   Fecha: viernes, 4 de noviembre de 2016, 23:14
   Para: JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>>
   CC: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
   Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

       * JORDI PALET MARTINEZ

The abstract explicitly states: The document also covers IP
transition technologies.

       Tore

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Sat, 5 Nov 2016 11:59:10 -0700

Speaking for myself.

One of the things that I would draw out of your list is that there is no market consensus. A vendor decides what features to put in a product based not on what the standards require, but what customers require. If he can’t sell more of a product by adding a feature, he has little argument for adding it. And the vendors see little revenue benefit to adding random transition technologies.

My personal guess, not based on data, of actual requirements is CGN for IPv4 in some form (could be translation to IPv6 or translation to another IPv4 address) plus native IPv6. 464XLAT adds NAT64 at a network boundary, and is an ISP issue. “Dual Stack” was intended to mean that one could turn IPv4 off or IPv6 off and have full operation either way, but was running both at the same time. “Dual Stack” as implemented usually means that some functionality requires IPv4 but IPv6 data is transported. The rest of what you mention are tunneling technologies in one form or another, a way to have IPvX be able to work around an IPvY-only domain. Again, those are usually ISP options - the ISP wants to deliver IPv6 service to residential customers, perhaps, but has an IPv4-only service between it and its customer, or the ISP wants to deliver dual stack service to a residential customer but is itself IPv6-only. Vendors will deliver to ISPs what the ISPs require in their RFI/RFQ.

If one can demonstrate a consensus, a standard shouldn’t be difficult to write or argue for. Absent that, I’m not holding my breath.

> On Nov 5, 2016, at 2:54 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
>

---

From: Alejandro D'Egidio <[email-masked]>
Date: Mon, 7 Nov 2016 10:35:48 -0300 (ART)

Dears,
  RFC6877 was released in April 2013 and RFC7084 was released in November 2013.
  If RFC6877 doesn't need any update yet, it's ok I think but since November 2013 until now appeared now definitions like RFC7599 and RFC7597 (July 2015).
  In RFC7084 section "4.4. Transition Technologies Support" is specified 6RD and DS-Lite.
  Do you really think that 6RD "must" be supported in a CPE of 2016?
  RFC7084 puts 6RD as a Transition Technologies Support and doesn't it include 464XLAT, MAP-T, MAP-E?

  On the other hand, in CableModems is not included 464XLAT (CLAT) yet because vendors don't want to include it. I have talked to Sagemcom, Technicolor and Cisco (now Cisco sold CPEs to Technicolor); they don't want implement it because they don't have enough requirements yet (how many are enought?) and if I want it I should request it to Broadcom (vendor of chipset included in all these CMs). Ok, I've talked to Broadcom also and they neither want to implement it because they say that they have DS-Lite, for them it works and we don't need any other protocol. I can not beleive this kind of answer.

  I have included RFC6877 in RFPs for new CMs as a mandatory feature but no one wanted to perform with this feature, so I had to remove it as a mandatory because if not I wouldn't be able to buy anyone.

  Regarding CGN, as we don't have more public IPv4, we didn't have any other option than deploy a CGN. For now, customers have Dual Stack (private IPv4 + IPv6).
  Lets think that with the inclusion of (for example) 464XLAT, ISPs like us won't need to deploy IPv4 (in normal cases).

Regards,

Alejandro D'Egidio 

----- Mensaje original -----
De: "Fred Baker" <[email-masked]>
Para: "JORDI PALET MARTINEZ" <[email-masked]>
CC: [email-masked]
Enviados: Sábado, 5 de Noviembre 2016 15:59:10
Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

Speaking for myself.

---

From: Hemant Singh <[email-masked]>
Date: Mon, 7 Nov 2016 09:12:27 -0500

+1 to Barbara.  Service providers who deploy landline Internet access such
as cable and DSL should come forward to v6ops and give their input if they
would like to deploy 464XLAT.  I also agree with RajivA on MAP-T/E.
Further, it was rfc6204 which was an IPv6-only CE router requirements doc.
It was rfc7084 that added transition tech because the WG asked for it and
the transition tech there were RFCs at the time was added.

Hemant

On Mon, Nov 7, 2016 at 8:35 AM, Alejandro D'Egidio <
[email-masked]> wrote:

>   If RFC6877 doesn't need any update yet, it's ok I think but since
> November 2013 until now appeared now definitions like RFC7599 and RFC7597
> (July 2015).
>   On the other hand, in CableModems is not included 464XLAT (CLAT) yet
> because vendors don't want to include it. I have talked to Sagemcom,
> Technicolor and Cisco (now Cisco sold CPEs to Technicolor); they don't want
> implement it because they don't have enough requirements yet (how many are
> enought?) and if I want it I should request it to Broadcom (vendor of
> chipset included in all these CMs). Ok, I've talked to Broadcom also and
> they neither want to implement it because they say that they have DS-Lite,
> for them it works and we don't need any other protocol. I can not beleive
> this kind of answer.
>
>   I have included RFC6877 in RFPs for new CMs as a mandatory feature but
> no one wanted to perform with this feature, so I had to remove it as a
> mandatory because if not I wouldn't be able to buy anyone.
>
>   Regarding CGN, as we don't have more public IPv4, we didn't have any
> other option than deploy a CGN. For now, customers have Dual Stack (private
> IPv4 + IPv6).
>   Lets think that with the inclusion of (for example) 464XLAT, ISPs like
> us won't need to deploy IPv4 (in normal cases).
>
>
> Regards,
>
> Alejandro D'Egidio
> ESTE MENSAJE ES CONFIDENCIAL. Puede contener información amparada por el
> secreto profesional. Si usted ha recibido este e-mail por error, por favor
> comuníquenoslo inmediatamente vía e-mail y tenga la amabilidad de
> eliminarlo de su sistema; no deberá copiar el mensaje ni divulgar su
> contenido a ninguna persona. Muchas gracias.
>
> THIS MESSAGE IS CONFIDENTIAL. It may also contain information that is
> privileged or otherwise legally exempt from disclosure. If you have
> received it by mistake please let us know by e-mail immediately and delete
> it from your system; should also not copy the message nor disclose its
> contents to anyone. Many thanks.
>
> One of the things that I would draw out of your list is that there is no
> market consensus. A vendor decides what features to put in a product based
> not on what the standards require, but what customers require. If he can’t
> sell more of a product by adding a feature, he has little argument for
> adding it. And the vendors see little revenue benefit to adding random
> transition technologies.
>
> My personal guess, not based on data, of actual requirements is CGN for
> IPv4 in some form (could be translation to IPv6 or translation to another
> IPv4 address) plus native IPv6. 464XLAT adds NAT64 at a network boundary,
> and is an ISP issue. “Dual Stack” was intended to mean that one could turn
> IPv4 off or IPv6 off and have full operation either way, but was running
> both at the same time. “Dual Stack” as implemented usually means that some
> functionality requires IPv4 but IPv6 data is transported. The rest of what
> you mention are tunneling technologies in one form or another, a way to
> have IPvX be able to work around an IPvY-only domain. Again, those are
> usually ISP options - the ISP wants to deliver IPv6 service to residential
> customers, perhaps, but has an IPv4-only service between it and its
> customer, or the ISP wants to deliver dual stack service to a residential
> customer but is itself IPv6-only. Vendors will deliver to ISPs what the
> ISPs require in their RFI/RFQ.
>
> If one can demonstrate a consensus, a standard shouldn’t be difficult to
> write or argue for. Absent that, I’m not holding my breath.
>
> > Some of those trials have been running for a couple of years already,
> and the reason not to go into commercial is precisely because they will
> prefer to use the same transition mechanism in all the network (they are
> using 464XLAT in the cellular trial), but the vendors aren’t supporting it
> and one of the arguments is not suggested as a requirement from the IETF ...
> >
> > In addition to all that, there are some other access technologies being
> used, with different transition mechanisms.
> >
> > By the way, most of the 464XLAT deployments are done using OpenWRT,
> taking advantage of existing CPEs that can be reflashed, because lack of
> support from the original vendors.
> >
> > The survey got already 1.223 responses up to now. I’m providing here
> only the numbers for those that responded with specific details about the
> transition technology. There are many other answers with have left this
> empty, probably customers that don’t know. In general, more complete
> responses come from the ISP employees, which also provide the contact
> details, and I talked with them in some cases to clarify specific answers
> to the survey.
> >
> > 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: Ca By <[email-masked]>
Date: Mon, 07 Nov 2016 18:01:50 +0000

Fyi, 464xlat is in openwrt for folks looking for it in home gateways

https://lwn.net/Articles/657119/

On Mon, Nov 7, 2016 at 5:36 AM Alejandro D'Egidio <
[email-masked]> wrote:

> > Slides -
> https://ripe73.ripe.net/presentations/22-IPv6-survey-October-2016.pdf

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 7 Nov 2016 19:40:31 +0000

>   Do you really think that 6RD "must" be supported in a CPE of 2016?

RFC 7084 does not mandate 6rd (not a "must"). It says SHOULD and then goes on to provide the conditionally mandatory requirements of *if* implemented, then the customer edge router (CER) MUST...
Same with DS-Lite. And I would only support other transition technologies going into a bis with the same sort of conditionality.
With that said, after RFC 7084 was published, I was able to get 2 retail CERs with 6rd to connect to my 2 different ISPs (one cable and one telco). Both ISPs at the time supported 6rd. But since then, things have changed. The cable provider 6rd starting behaving badly, so I had to disable it, though they still publish the 6rd settings. The telco has now run PON to customers who formerly could use retail CERs to connect, and requires telco equipment in the CER position (and has stopped publishing 6rd settings because they configure their own equipment automatically). I still have my router behind the CER, but the IPv6 service looks like dual stack at the point (with the CER providing a /64 by IA-PD to my retail router). I think experience with 6rd suggests that it only ever provided high IPv6 penetration where the ISP supplied the equipment. Note that while http://www.worldipv6launch.org/measurements/ shows AT&T (wireline) at over 58% (out of about 16 million customers) and this is all 6rd, that is almost all due to 6rd support in AT&T-provided CER and not retail. This operator-supplied CER was driven more by requirements in BBF TR-124 (which preceded RFC 7084), and not RFC 7084 (which really was aimed more at retail).
So if the point was that 6rd is not currently deployed or not used, I would disagree. But if the point is that 6rd has only ever been successful when the CER was supplied by the operator; so including it in retail CER requirements (RFC 7084) doesn't add value to the mass market at this time; I would tend to agree. And my feelings wouldn't be hurt if it were removed. I would also agree that it makes no sense to add any other v6-tunneled-over-v4 technologies to RFC 7084. Only v4 over v6 should be considered.

> include 464XLAT, MAP-T, MAP-E?

The technologies included in RFC 7084 were the ones ISPs participating in v6ops said they were intending to use. ISPs who did not participate did not provide input. Note that RFC 7084 was actually finished over a year before it was published, but had to wait on RFC 7083. Work on it was complete before 464XLAT, MAP-E, or MAP-T RFCs; and while it was waiting for RFC 7083, people were busy creating test specs for it and doing plugfests and such. It was very much frozen for that year.
 
> implement it because they don't have enough requirements yet (how many
> are enought?) and if I want it I should request it to Broadcom (vendor of
> chipset included in all these CMs). Ok, I've talked to Broadcom also and they
> neither want to implement it because they say that they have DS-Lite, for
> them it works and we don't need any other protocol. I can not beleive this
> kind of answer.

None of the ISPs participating in RFC 7084 were expecting to drive requirements into operator-procured CER. I see the most recent CableLabs eRouter spec (https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-specification/) has requirements for optional DS-Lite, MAP-E, and MAP-T. So requirements for cable modems exist for these, and it sounds like DS-Lite units are readily available. It seems (from a quick online search) there are cable modems with MAP-E and MAP-T, too. 464XLAT isn't documented in any CableLabs requirements. I suspect lack of cable modems with 464XLAT is due more to the fact that it isn't in CableLabs eRouter specs, than its absence from RFC 7084.
 
>   I have included RFC6877 in RFPs for new CMs as a mandatory feature but no
> one wanted to perform with this feature, so I had to remove it as a

With the majority of cable operators choosing DS-Lite, MAP-E, or MAP-T (if not simple dual stack with CGN where needed), I think it will be really hard to get a critical mass of cable providers to ask for cable modems with 464XLAT. I don't think RFC 7084 had any influence on cable modems, because of the eRouter specs. I sympathize and hear your frustration, but I'm not convinced an update to RFC 7084 (or anything from IETF) will help with this.

With that said, I have no objection to expanding the list of optional v4-tunneled-over-v6 technologies in RFC 7084. But if I were a vendor, I think I would be very frustrated that operators felt they needed 5 different ways (native, MAP-E, MAP-T, DS-Lite, and 464XLAT) of providing a service that to the average customer all look identical. I don't see an update to RFC 7084 as being likely to drive cable modem development. I don't expect it to drive retail development either, at this point. My expectation of the retail vendors is that they'll look at large operator deployments and base decisions on that much more than on an IETF RFC.
Barbara

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Sun, 27 Nov 2016 19:08:13 +0200

Hello,

RFC 7084 (and 6204 before that) was used by us (ISPs) to push vendors to 
implement IPv6 deployment-related features. Before that, every ISP would 
write down their own specs, with various degrees of success. So, 7084 
was and still is a very good thing!

Now, as an ISP deploying (not thinking about, actually deploying as we 
speak) lw4o6 to potentially 1.5M users, I'd really prefer if 7084 
included lw4o6/MAP etc, not so much for my ISP, but for others that are 
still considering their options. I really see no reason whatsoever, for 
not updating 7084 (and also keeping existing transition technologies in 
place). BTW, lw4o6 support is mandatory in our CPE tenders (and so it is 
for the rest of DT group AFAIK)

cheers,

Yannis