Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

["Rajiv Asati (rajiva)" <[e-mail]>]

>    Do you agree with my changes 1, 2, 3 and 4 above?
  
Yes

>    Now a more complex question. Do you think it will be acceptable for 3 and may be 4 above, to be a MUST instead of just SHOULD?
  
Yes. 


-- 
Cheers,
Rajiv  

-----Original Message-----
From: v6ops <[e-mail]> on behalf of JORDI PALET MARTINEZ <[e-mail]>
Reply-To: "[e-mail]" <[e-mail]>
Date: Tuesday, February 21, 2017 at 4:11 AM
To: "[e-mail]" <[e-mail]>
Subject: [v6ops] FW: New Version Notification for	draft-palet-v6ops-rfc7084-bis-00.txt

    Hi,
    
    I’ve submitted a -bis draft for updating RFC7084 (Basic Requirements for IPv6 Customer Edge Routers).
    
    The basic idea behind this update is to consider that the ISPs have not more IPv4 addressed so they will need to make sure that CEs are capable of running on IPv6-only links, but including some support for IPv4 transition, so the customer LANs can still use IPv4 for older devices or apps, until they become updated.
    
    The approach of the RFC7084 was to rely either in 6rd (which requires dual stack on the WAN link), or DS-Lite (which required dual stack by means of CGN with private IPv4 addressed for the WAN).
    
    My view, considering the time frame when this document may be accepted by the WG and then the time that vendors can take to implement new firmware versions or new products (almost one year from now), is that more and more ISPs will have troubles to use 6rd (which by the way is not being used too much), or will prefer other solutions than CGN.
    
    So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as SHOULD.
    
    In my version:
    
    1) Considering that there’re no more IPv4 addresses and according to my experience with service providers, they will prefer to avoid dual stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to be changed to MAY.
    
    2) At the same time, I’ve included lw4o6, also with MAY. The rationale for this: Many service providers try to avoid the CGN, and lw4o6 is a way to do so, without increasing the cost of the CE. Basically, a CE that supports a regular IPv4 NAT+DS-Lite, is already capable of supporting lw4o6. The cost in terms of CE flash memory for DS-Lite is about 1Kb. The open source package available for DS-Lite that I’ve been digging-in takes 6Kb, but already includes also support for both MAP versions.
    
    3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those protocols are the 3 alternatives that a service provider has to deploy IPv6-only WAN, but at the same time provide dual-stack in the LANs, with practically the same functionalities or even more, that what CGN requires. At the service provider network, it requires, instead of CGN, a stateful NAT64 (which cellular providers are already using) or a Border Relay (for MAP). Basically, a CE needs only 3Kbytes of code in the flash to support CLAT (the CE part of 464XLAT). The support for MAP (both versions and also lw6o4), requires about 6Kb.
    
    4) Include support for 6in4 as SHOULD. The rational for this: According to my experience, sometimes, business customers (specially SMEs) are in the same access network as residential ones, but they are provisioned manually and often require dual-stack with public IPv4 addresses, because they have to publish external services such as VPNs, or others that may not yet rely in an IPv6-only network. I’ve seen cases of service providers with 10.000 customers and 250 of those “SMEs”, and all them are provisioned manually because don’t make sense to find an automatic configuration. So, I think we must keep this support, with typically is already available in any dual-stack router today. In fact, if the router supports 6to4 or 6rd, the 6in4 support is already there. In terms of flash utilization, 6in4 requires 1Kb, 6rd 2Kb and 6to4 1Kb.
    
    Note than I’ve been looking for the “cost” of the flash memory into open source available as GPLv2, which also means that the impact for any vendor in “updating” available firmware of actual CEs is minimal, if any, and is more an “integration” cost, probably a very few hours+testing. In fact, there are a few vendors that have it already (unfortunately very few) and I heard about some that offered it to “special big customers”, but not offered to the “general market”.
    
    I’ve been evaluating myself, with trial customer deployments, using open-source such as OpenWRT/LEDE, the cost/functionally of those transition mechanisms and they just work. Typical CE today have a minimum of 8MB (market moving quickly to 16 or 32 MB) flash memory and 32MB (market moving quickly to 64GB and much more) RAM, and they hold perfectly all those features without any issue and without needed to take out other code.
    
    So, the questions for the WG:
    
    Do you agree with my changes 1, 2, 3 and 4 above?
    
    Now a more complex question. Do you think it will be acceptable for 3 and may be 4 above, to be a MUST instead of just SHOULD?
    
    I think vendors need a very strong signal here, otherwise, many of them (and this is happening), are reading actual 7084 and only reacting to implement those transition technologies with specific firmware versions for “very big” customers which will buy several hundred thousand units in one shot. But many small and medium service providers, buy only a few units every week when they connect new customers. This was discussed already in this list a couple of months ago.
    
    https://www.ietf.org/mail-archive/web/v6ops/current/msg25152.html
    
    Please, note that that this document version doesn’t include yet the details of the requirements for each transition mechanism. I’m working on those already, but will be nice to have some inputs from the WG, regarding my questions above.
    
    Regards,
    Jordi
     
    
    -----Mensaje original-----
    De: <[e-mail]>
    Responder a: <[e-mail]>
    Fecha: lunes, 20 de febrero de 2017, 23:37
    Para: Jordi Palet <[e-mail]>, Jordi Palet Martinez <[e-mail]>
    Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt
    
        
        A new version of I-D, draft-palet-v6ops-rfc7084-bis-00.txt
        has been successfully submitted by Jordi Palet Martinez and posted to the
        IETF repository.
        
        Name:		draft-palet-v6ops-rfc7084-bis
        Revision:	00
        Title:		Basic Requirements for IPv6 Customer Edge Routers
        Document date:	2017-02-20
        Group:		Individual Submission
        Pages:		22
        URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-rfc7084-bis-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis/
        Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-00
        
        
        Abstract:
           This document specifies requirements for an IPv6 Customer Edge (CE)
           router.  Specifically, the current version of this document focuses
           on the basic provisioning of an IPv6 CE router and the provisioning
           of IPv6 hosts attached to it.  The document also covers several
           transition technologies, as required in a world where IPv4 addresses
           are no longer available, so hosts in the customer LANs with IPv4-only
           or IPv6-only applications or devices, requiring to communicate with
           IPv4-only services at the Internet, are able to do so.  The document
           obsoletes RFC 7084.
        
                                                                                          
        
        
        Please note that it may take a couple of minutes from the time of submission
        until the htmlized version and diff are available at tools.ietf.org.
        
        The IETF Secretariat
        
        
        
    
    
    
    **********************************************
    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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/v6ops