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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 21 Feb 2017 10:11:40 +0100

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: <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 20 de febrero de 2017, 23:37
Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
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.

---

From: Nathalie Trenaman <[email-masked]>
Date: Tue, 21 Feb 2017 10:32:19 +0100

Hi Jordi,

<snip>

> So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as SHOULD.

While I agree with most things listed below, and I also agree with your points changing 6rd to “MAY”, I don’t agree on changing DS-LITE to “MAY”. I would leave it with “SHOULD”. 
Some really large residential deployments chose for DS-LITE a while ago, (before MAP was standardised) and won’t change their plans soon. They already purchased the CGNAT equipment, etc. Their IPv6 deployment takes years….(from what I hear in all the IPv6 courses)
So, DS-LITE is a “SHOULD”, not (yet) a “MAY” but also not a “MUST”

Just my 2 cents. 

Nathalie

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

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 Feb 2017 18:39:52 +0900

And AT&T has a very large 6rd deployment, so I wouldn't be surprised to see
push back from them on downgrading 6rd to MAY (though perhaps they don't
much care, idk).

It's hard to see how this discussion won't just degrade into "my deployment
technology should be SHOULD or even MUST, everyone else can be MAY".

On 21 February 2017 at 18:32, Nathalie Trenaman <[email-masked]> wrote:

> While I agree with most things listed below, and I also agree with your
> points changing 6rd to “MAY”, I don’t agree on changing DS-LITE to “MAY”. I
> would leave it with “SHOULD”.
> Some really large residential deployments chose for DS-LITE a while ago,
> (before MAP was standardised) and won’t change their plans soon. They
> already purchased the CGNAT equipment, etc. Their IPv6 deployment takes
> years….(from what I hear in all the IPv6 courses)
> > 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.
> >
> > 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.
> >
> > 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
> >
> >
> >    URL:            https://www.ietf.org/internet-
> drafts/draft-palet-v6ops-rfc7084-bis-00.txt
> > 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: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 21 Feb 2017 11:01:26 +0100

Responding to Nathalie and Erik, 

First thanks to both for the quick response!

I think it will be ok to keep SHOULD for both 6RD and DS-LITE, in fact there is no impact, if we include the other protocols, in terms of “how much” memory they take from the flash.

However, those big deployments that you both mention, are “already” done, so their actual vendors will, for sure, make sure to keep those customers, so it means they will keep 6RD/DS-Lite even if it is a MAY and competitors will also include support if they want to become providers for CEs to those service providers, right?

The main issue here is to support new “IPv6-only” in the WAN, but dual-stack in the LANs, deployments.

Anyway, as said, I’m happy to turn again to SHOULD both of those, as there is no impact. Let’s see if other folks can tell us what they think!

What do you think about moving the 464XLAT, MAP, to MUST ?

Regards,
Jordi

-----Mensaje original-----
De: Erik Kline <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 21 de febrero de 2017, 10:39
Para: Nathalie Trenaman <[email-masked]>
CC: Jordi Palet Martinez <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

    And AT&T has a very large 6rd deployment, so I wouldn't be surprised to see push back from them on downgrading 6rd to MAY (though perhaps they don't much care, idk).
    It's hard to see how this discussion won't just degrade into "my deployment technology should be SHOULD or even MUST, everyone else can be MAY".

    Hi Jordi,
    
    <snip>

    
    Just my 2 cents.
    
    Nathalie

    >    until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
    >
    >    The IETF Secretariat
    >
    >
    >
    >
    >
    >

---

From: Nathalie Trenaman <[email-masked]>
Date: Tue, 21 Feb 2017 11:13:16 +0100

Hi Jordi,

> On 21 Feb 2017, at 11:01, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

Ok.

> What do you think about moving the 464XLAT, MAP, to MUST ?

Agreed. 

Nathalie

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Feb 2017 12:47:01 +0100 (CET)

Hi,

One thing that happened to me as of late has made me consider what the CE 
should do in this situation. I think most of the text in the current 
document agrees with what would like to happen, but there might be 
opportunity for one of two new requirements.

My current situation is that I have a statically configured 6in4 tunnel to 
my CE, because my ISP doesn't support native IPv6.

My ISP started sending me RAs with no prefix in them, M=1, and responds to 
requests for IA_NA and IA_PD with "NoPrefixAvail".

My UBNT ER5 overwrites the static ::/0 route I have over the 6in4 tunnel 
and points default to the ISP router (breaking my connectivity). In the 
routing table, it says "proto RA" for that route. Changing distance on my 
static route doesn't help. I ended up having to firewall ICMP6 from my ISP 
towards the ER5 so it wouldn't even see the RAs, and I will continue doing 
this until my ISP deployment is done. Now I have a working soltion again.

My Omnia Turris (running OpenWrt variant) in the same environment (but 
without 6in4 tunnel), seems to consider these RAs and the lack of 
prefix/address as a reason to just ignore them. It doesnt install a 
default route (so I don't have a ::/0 route on it at all on it).

Do we want some text in the document on what to do with RAs of different 
types? What about if it gets an native RA when it has 6RD configured and 
working? Which should be preferred? If it now has multiple prefixes, 
should it announce all of them? Just one?

The current document just touches on what the device should announce and 
configure onto its LAN interfaces when certain things happen, it doesn't 
touch on how different situations should influence what routes to 
configure in itself, what things to prefer etc?

Should we have source routing requirements, as discussed in homenet? My 
situation wouldn't have been a problem if I had installed a source/address 
based ::/0 route towards my 6in4 tunnel that would have taken precedence 
over the non-SADR route learnt from the RA?

I know we don't want to make this document hugely more complicated, but 
where do we draw the line? Do we want to support transition from for 
instance 6RD to native in a not-too-disruptive-consumer-experience way?

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 Feb 2017 11:58:59 +0000

>    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 <[email-masked]> on behalf of JORDI PALET MARTINEZ <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Tuesday, February 21, 2017 at 4:11 AM
To: "[email-masked]" <[email-masked]>
Subject: [v6ops] FW: New Version Notification for	draft-palet-v6ops-rfc7084-bis-00.txt

    Hi,

    

    
    In my version:

    

    

    

    
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 20 de febrero de 2017, 23:37
    Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
    Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

        Abstract:

        
        
        The IETF Secretariat

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Feb 2017 13:55:44 +0100

>default route (so I don't have a ::/0 route on it at all on it).

I guess this is something that could be fixed with source-dest routing.

The 6in4 tunnel should be preferred for source addresses associated with the
tunnel. 

The default route from the RA can be added but won't be used because of 
longest prefix matching on the source address.

(Just not accepting a default route because there are no associated addresses
may break other setups)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 21 Feb 2017 14:23:01 +0100 (CET)

Hi,

another potential mechanism to be included in 7084bis.

https://tools.ietf.org/html/rfc8026

This should probably be supported by a 7084bis device. If there are 
mechanisms in 7084bis not in RFC8026, that should probably be added.

Also, please do not downgrade MUST requirements in 7084 to anything less 
in 7084bis. That means an ISP supporting for instance DS.lite can have 
reasonable "trust" in that a 7084bis device will still support this.

We don't want to drive ISPs to support all/most mechanisms just because 
the CEs don't support at least one mandatory one (and that this changed 
over time).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ian Farrer <[email-masked]>
Date: Tue, 21 Feb 2017 15:00:15 +0100

Hi Jordi,

> What do you think about moving the 464XLAT, MAP, to MUST ?

[if - RFC7084 already has MUST requirements for 6RD and DSLite and as they are already widely implemented would like them to stay as MUST. However, I would prefer not to see any more mandatory transition mechanisms added in this document.

I think it’s more useful to construct the requirements for any of the newer (post RFC7084) transition mechanisms, as ‘MAY implement the mechanism - if implemented MUST support a, b, c'. When specifying requirements for a CPE, I can just point to the particular section relevant to the mechanism deployed in my network.

Regards,
Ian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 21 Feb 2017 19:19:47 +0000

Some of my thoughts on things that have been said ...

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

I'm not aware of any vendors *who sell to ISPs* and use RFC 7084 as the basis for what they put in their firmware. Most such vendors use BBF TR-124 or CableLabs CE Router specs. As an author of RFC 7084, I really saw this RFC as targeting the retail vendors. That was my reason for working on it. If all I needed was requirements for vendors to ISPs, BBF TR-124 would have been sufficient. 
I do sympathize with the small ISPs. I just wonder if this is the right way to do it. I wonder if a completely new (not modified RFC 7084) draft whose intent is clearly stated as being to specify additional transition functionality needed by many small ISPs might be a better approach. It might be good to strategize on the best way to achieve this desired goal, rather than first discussing what requirements are MUST/SHOULD/MAY. And also agree on this as the goal of a new draft.
It may be more effective to have a small targeted draft that says "do mandatory dual stack parts of RFC 7084; and here is additional transition technology that many small ISPs need to be able to get from their vendors". 
We would need a number of smaller ISPs to join in support, if it's to be successful. And the set of requirements definitely need to be limited.
If that were the focus of the draft, I wouldn't bother including 6rd at all.

> And AT&T has a very large 6rd deployment, so I wouldn't be surprised to see push back from them on downgrading 6rd to MAY (though perhaps they don't much care, idk).

At this point, for me, it's a "don't care". When deployment first started, there was a distinct percentage of AT&T customers who had no (and no option for) AT&T-provided CE Router (because of a legacy broadband architecture in the southeast US). As I mentioned, RFC 7084 was about retail and not ISP-procured CE routers -- so having 6rd in retail routers provided these customers (including me) a way to get 6rd up and running on AT&T. Over the past 1.5 years, AT&T has put FTTH in place for almost all (or maybe by now all) those customers, which means AT&T CE routers are available (and for FTTH, required). You can't even find the 6rd configuration info on the AT&T website anymore. [You can still find the info where other people have posted it. Just not from AT&T.] 
I do have my own CE router behind the AT&T CE router. The AT&T CE router provides a /64 from the 6rd /60 via IA_PD to my router. So it looks to my router like native IPv6.
AT&T configured and enabled 6rd, LAN-side SLAAC, and LAN-side DHCPv6 IA_PD in the AT&T CE Router, without my doing anything.

Barbara

---

From: james woodyatt <[email-masked]>
Date: Tue, 21 Feb 2017 12:21:39 -0800

> I’ve submitted a -bis draft for updating RFC7084 (Basic Requirements for IPv6 Customer Edge Routers).

I strongly believe that any update to RFC 7084 that doesn’t REQUIRE the LAN interfaces to provide HNCP services [RFC 7788] is an incomplete update.

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Feb 2017 00:41:51 +0000

Sorry, James, I disagree.
The charter of v6ops is still doing things that help get IPv6 rolled out. Which is exactly what these ISPs are asking for help with. Which has nothing to do with multi-router home network topologies.

I believe a very targeted document to meet the needs of these ISPs is what we should be aiming for.
Barbara

From: v6ops [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, February 21, 2017 3:22 PM
To: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

On Feb 21, 2017, at 01:11, JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Feb 2017 17:09:23 -0800

This argument is essentially what I was referring to with respect to draft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812 didn't have to address. They include, at least, ISP, content network, data center, enterprise, residential, IoT, and mobile wireless networks. Those markets have differing non-exclusive sets of requirements.

Let me throw a question to the working group. One way to approach this is to try to push requirements for all of those markets into one document, which is what I think James is trying to do. Another way is to separate them, which is what I think Barbara is trying to do. I'm not going to say that either is automatically right or automatically wrong, but they are different, and I have visions of an argument that takes forever, boils blood, and nobody wins, if we don't systematically address it.

I see two approaches that might be considered reasonable. One would be to add a section about residential networks (which are definitively not ISP networks, but use routers that might also be used as ISP "customer-edge" routers) to the document, stating that it is requirements for routers that might be used within a multi-router residential network including the router connected to the ISP; the other would be to invite a separate document that addresses residential networks.

If we take the latter approach, we might as well also invite separate documents (or in the former approach, separate sections) describing requirements for IPv6 routers in ISP, content network, data center, enterprise, IoT, and mobile wireless networks. This might be one of those, and draft-ali might be one of those. I suspect we will find that a lot of the requirements are in fact common, and could be described in a core document. But I don't know of any ISPs suggesting the use of HNCP, residential networks discussing RPL, or yada yada yada.

Opinions?

On Feb 21, 2017, at 4:41 PM, STARK, BARBARA H <[email-masked]> wrote:
> --james woodyatt <[email-masked]>
>  
>  
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Feb 2017 17:17:26 -0800

> This argument is essentially what I was referring to with respect to draft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812 didn't have to address. They include, at least, ISP, co…
Is there a way to focus on the core requirements that all routers need
to support in this doc, assuming that there are lots of things a router
in general MAY also do...

And then leave it to other documents to focus on the additional
requirements (or relaxations of SHOULDs) that apply to these environments?

Joe

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Feb 2017 17:29:04 -0800

> On Feb 21, 2017, at 5:17 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

There may be; it would be the "core document" I referred to. A document that is accurately described as "7084-bis" would not be that document; 7084 describes a router in a particular application, and probably a particular price point, something called "customer-edge".

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Feb 2017 08:47:50 +0100

Hi Barbara,

I’m trying to understand what was the goal for the original document. You mention “retail vendors”.

Not being a native English speaker I really feel that I’m in the limit to understand correctly what is a “retail” vendor and what are the other types, so to understand what makes them different in terms of requirements.

At this way I think we can take a better decision if we want a single document or separate ones.

Regards,
Jordi

-----Mensaje original-----
De: "STARK, BARBARA H" <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 21 de febrero de 2017, 20:19
Para: "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: RE: [v6ops] New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

    

    
    Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Feb 2017 08:50:39 +0100

I tend to agree on that, but also agree that we need to decide if we really need two or more documents or a single one.

The main issue I see is that looking at open-source, HNCP requires 200Kbytes of code. It is probably still possible in most of the today routers, so should not be a problem, but it is required in a router for a SME?

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Feb 2017 09:10:18 +0100

HI Fred,

My initial view on this.

I prefer in general a single document. I think 7084 is a good starting point.

I look into the reality of the market.

Most of the CEs/CPEs that are being sold/installed are used in several scenarios:
1) Pure residential
2) Residential with small home office
3) Residential/techie (with or w/o home office) that have exported services (email server, web server, VPN server, etc.).
4) Small home office
5) SMEs with just use Internet for “browsing”, emailing, etc.
6) SMEs as in the previous case that also have exported services (email server, web server, VPN server, etc.).

Those CPEs are in the range of 15USD to 150USD, but even much more expensive (up to 500USD) if they have sophisticated WiFi support. This is very common for gammers.

Then we have other cases for big corporates. Those typically use more expensive equipment, WiFi with APs, etc. In this case, there is a “smart” and conscious decision, typically there are engineers that design the network, or an external company, and decide what equipment they need and what are the required features. I also believe that in many cases, the required features may be the same as for 6 above.

I believe the cases that you mention as content providers, data centers, etc, etc., are probably closer to the big corporates model that I just mention, and to be honest, I don’t know if we need to say what are the requirements, as I tend to believe that the market is doing it correctly. We can just have a section in the document explaining this scenario, but not sure if we need a new/different document for this.

What James indicated may be not required for 6, but is in the “limit”.

So looking into this, I believe that it will be much better, easier and less confusing, to evolve 7084, and if required, include some text/section with possible target scenarios and state there “this may be not required in this scenario” (just an example).

I believe draft-ali-ipv6rtr has a different scope, but I will need to read it again to make sure. 7084 seems to be the right place because it has already a good base of what we intend to do (in my opinion).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Fred Baker <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 22 de febrero de 2017, 2:09
Para: IPv6 Ops WG <[email-masked]>
Asunto: [v6ops] Requirements for IPv6 routers in various locations

    

    Opinions?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Feb 2017 09:18:25 +0100

Can we define what is a customer edge? Is it different than what I’ve mention in my previous email:

1) Pure residential

In my opinion is the router provided to residential customers, SMEs, etc., by 95% of the access links in the world and even sold in markets so customer can buy a new one if broken or a better one with better WiFi support to replace the one that the ISP deployed.

Some ISPs just provide a “modem” or “bridge” and is the customer the one that need to buy it.

Some ISPs make their own as OEM devices from vendors, or have such volume that get their logo on it and even specific firmware versions.

Smaller ISPs need to go to the local market to buy them because they need smaller quantities and have no way to ask for “features” which they need. Same as when you buy it in the local store, you will find what is generally available and can’t ask for a special software.

Regards,
Jordi

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Feb 2017 00:22:36 -0800

> On Feb 21, 2017, at 11:47 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

I think she is comparing equipment that is sold to an ISP and used in a managed service (which would be specified by a Cable Labs or Broadband Forum document) to equipment that is sold in a store, purchased by the user, and installed by them. I don't know what you have in Spain, but we have both types of service; the router in my home was purchased by me and is not managed by my ISP, but AT&T (and other ISPs) have equipment that they install as part of a service managed by the ISP.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 22 Feb 2017 09:29:16 +0100

Hi Jordi,

* JORDI PALET MARTINEZ <[email-masked]>

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

I believe this document should not attempt to rank between IPv6
transition technologies. If you say that transition tech Foo is SHOULD
while Bar is MAY you're suggesting that Foo is somehow better or more
relevant than Bar.

The actual ranking of such a list does however depend entirely on the
deployment models of the ISPs operating in the market the device is
being targeted at. There's no universal ranking here, no single
technology that has «won» yet.

So if you really need to make this «IPv6 CE router» document almost as
much about IPv4 as it is about IPv6 by listing all the available
transition technologies, the they should all be MAY.

Better yet, move them from the normative section into the appendix or a
separate document analysing and comparing all the various transition
technolgies.

> and may be 4 above, to be a MUST instead of just SHOULD?

Absolutely not.

Tore

---

From: Gert Doering <[email-masked]>
Date: Wed, 22 Feb 2017 09:30:05 +0100

Hi,

On Tue, Feb 21, 2017 at 12:21:39PM -0800, james woodyatt wrote:
> I strongly believe that any update to RFC 7084 that doesn???t REQUIRE the LAN interfaces to provide HNCP services [RFC 7788] is an incomplete update.

Seconded.  This is the way to go.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Feb 2017 09:49:01 +0100

I think vendors don’t see this as different equipment.

I’m working in all the RIR regions, not just Spain, and most of my customers are small and medium ISPs; some are big ones.

All them follow the model I mention before. If they place big orders, they speak directly to the CPE manufacturer, sometimes they agree on specific firmware modifications.

But in all the cases, end-users can buy their own CPE, replace the one provided by the ISP, or setup the one from the ISP in “bridge” mode and use their own behind the ISP one.

I don’t think vendors make a difference, in fact, all the routers that up to now I’ve seen provided and managed by the ISPs, can be also acquired in retail stores, Internet, etc. (sometimes same product different label).

In all my customers and all what I’ve seen up to now, even if this CPE is managed, this management can be disable by the users, because they have the legal right to do so (if we want to go to that point). They just need to use the same parameters/protocols as the original ISP supplied device was having (or as said have it configured in bridge mode).

So the point here is: I don’t think the vendors do different things for the products that go directly to the ISP and the retail market. Sometimes the difference is only that the products for the ISP have “some extra” functions or come pre-configured in some way, so I don’t see we need to have different documents.

Moreover, ISPs talking to vendors (usually big ISPs) will take 7084 (or a possible successor), as a starting point (as they do today), and ask the manufacturer to add what they need (even if it is not “standard”).

Saludos,
Jordi

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 Feb 2017 08:54:54 +0000

Hi,

> On 22 Feb 2017, at 08:49, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

It seems one option to is to have a base document (which might be 7084-bis) and then have a document that presents deployment scenarios and recommends specific functionality for those scenarios. For example, HNCP is certainly important in some scenarios. Such a complementary document could also cite the sources Barbara refers to. This might also be a way to present the “transition” mechanisms in a more coherent way.

Tim

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 22 Feb 2017 10:59:55 +0100

Hi Mikael,

You’re right, this should be included as part of the requirements, even if we don’t go for new transition mechanisms in a RFC7084, a –bis version is needed for DS-LITE to support that.

While reading the document I’m wondering if anyone believes there is a need for a new DHCP option for 464XLAT configuration with DHCPv6. I don’t think so, because in this case, all the “info” is provided via the DNS64 responses, but I may be missing something. Anyone having a different view?

Regards,
Jordi

-----Mensaje original-----
De: Mikael Abrahamsson <[email-masked]>
Organización: People's Front Against WWW
Responder a: <[email-masked]>
Fecha: martes, 21 de febrero de 2017, 14:23
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

    Hi,

---

From: james woodyatt <[email-masked]>
Date: Wed, 22 Feb 2017 12:09:48 -0800

Hi Barbara,

Please let me explain why that posture actually makes the roll out of IPv6 more difficult rather than less difficult. Consider the case of Thread™ border routers, which I am involved in the process of defining the best practices for implementation in the Thread Group.

    <https://www.threadgroup.org/Portals/0/documents/whitepapers/Thread%20Border%20Router%20white%20paper_v2_public.pdf <https://www.threadgroup.org/Portals/0/documents/whitepapers/Thread%20Border%20Router%20white%20paper_v2_public.pdf>>

The networks behind these border routers are IPv6-only. They are 6LoWPAN mesh networks. They are typically implemented in devices that join home LAN segments with Wi-Fi™.

If IETF updates RFC 7084 without including a strong recommendation to provide HNCP services on the LAN interfaces, it will serve as a very strong signal to groups like Thread™, which are currently working on such border routers, that IETF does not believe routers serving residential subnets should be provisioned with sufficient address space to support downstream routers, like Thread™ border routers.

That’s a big deal. It will have serious consequences.

People working on this stuff here at Google currently observe in the wild IPv6 home gateways, presumably RFC 7084 ones, that do not respond positively to DHCP-PD requests, either because they do not receive delegations of more space than a single /64 from service providers, or they do not have sufficient remaining space to respond positively to DHCP-PD requests because all the prefix space has been consumed by other clients.

So, how does one imagine such border routers will make hosts on those IPv6-only links behind them reachable via the public IPv6 Internet? There are several alternatives available in the event that RFC 7084 is updated without a recommendation to implement HNCP. Here are some ideas that I’m seeing my colleagues— experts in the field— seriously promote as things that SHOULD be done in that event:

1. Use NAT66 (not NPTv6, NAT66 with address and port translation) to masquerade the entire mesh behind the border router as the same IPv6 host on the home LAN segment (my hunch is this is the most likely alternative to be implemented, not the least, and for reasons that are very difficult to counter).

2. Use ND Proxy to masquerade the entire mesh behind the border router as the same Wi-Fi MAC address (this has problems related to interoperability with various Wi-Fi implementations, and it makes some people I know nervous, hence the attraction to NAT66 which trades those problems for more familiar problems already well understood in the IPv4 world).

3. Use NAT64+DNS64 to masquerade the entire mesh behind the border router as the same IPv4 host on the home LAN and just forget entirely about IPv6 (this is a required capability for dealing with IPv4-only service providers, which do still exist, sadly, and the idea we are considering here is to just never bother doing more than NAT64+DNS64 and therefore hope the whole IPv6 on the public Internet just blows over).

I don’t know about the rest of the V6OPS working group, but I think all three of these alternatives are terrible for everyone. Hence, it would be better if RFC 7084 is updated to include a strong recommendation to implement the HOMENET protocols. Just my 0.02 euros, your mileage may vary, offer not valid in the Bear Flag Republic.

Barbara, and anyone else taking a similar view, please please please reconsider your position.

---

From: t.petch <[email-masked]>
Date: Thu, 23 Feb 2017 11:04:36 +0000

----- Original Message -----
From: "Fred Baker" <[email-masked]>
Sent: Wednesday, February 22, 2017 1:09 AM

> This argument is essentially what I was referring to with respect to
draft-ali-ipv6rtr-reqs when I said we had multiple markets that RFC 1812
didn't have to address. They include, at least, ISP, content network,
data center, enterprise, residential, IoT, and mobile wireless networks.
Those markets have differing non-exclusive sets of requirements.
>
> Let me throw a question to the working group. One way to approach this
is to try to push requirements for all of those markets into one
document, which is what I think James is trying to do. Another way is to
separate them, which is what I think Barbara is trying to do. I'm not
going to say that either is automatically right or automatically wrong,
but they are different, and I have visions of an argument that takes
forever, boils blood, and nobody wins, if we don't systematically
address it.

Separate.

I think that most of the requirements documents fail, at least in part,
because they end up as the logical OR of everyone's wish list.  Look,
for example, at the little discussion currently in progress on the
wisdom or otherwise of /64.  Any one marketplace has its own clear view
but merge them together and you have a slight lack of agreement.

So let's have sets of requirements focussed on a marketplaces,
separately documented.

I always find Barbara's comments most insightful because she is
describing a world I have no knowledge of, of whose requirements I would
otherwise be unaware of; merge them into everyone else's and I would be
wondering what on earth is this doing here.

Tom Petch

> I see two approaches that might be considered reasonable. One would be
to add a section about residential networks (which are definitively not
ISP networks, but use routers that might also be used as ISP
"customer-edge" routers) to the document, stating that it is
requirements for routers that might be used within a multi-router
residential network including the router connected to the ISP; the other
would be to invite a separate document that addresses residential
networks.
>
> If we take the latter approach, we might as well also invite separate
documents (or in the former approach, separate sections) describing
requirements for IPv6 routers in ISP, content network, data center,
enterprise, IoT, and mobile wireless networks. This might be one of
those, and draft-ali might be one of those. I suspect we will find that
a lot of the requirements are in fact common, and could be described in
a core document. But I don't know of any ISPs suggesting the use of
HNCP, residential networks discussing RPL, or yada yada yada.
> > The charter of v6ops is still doing things that help get IPv6 rolled
out. Which is exactly what these ISPs are asking for help with. Which
has nothing to do with multi-router home network topologies.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 24 Feb 2017 13:19:33 +0000

> Can we define what is a customer edge?

RFC 7084 already includes a definition of what it means:

IPv6 Customer Edge Router:
a node intended for home or small-office use that forwards IPv6 packets not explicitly addressed to itself.  The IPv6 CE router connects the end-user network to a service provider network.

I would suggest not trying to change this definition of this term, because I think that would be confusing. If a more encompassing term is needed, I think it would be better to create a new term.
I would also be strongly opposed to any attempt at a RFC 7084 update that changed the scope of RFC 7084.

> 3) Residential/techie (with or w/o home office) that have exported services
> (email server, web server, VPN server, etc.).
> 4) Small home office

Clearly, 1, 2, and 4 are included in the RFC 7084 definition. If the needs of 3, 5, and 6 are met by a device designed for 1/2/4, then they are certainly welcome to use it. If such a device does not meet the needs of 3/5/6, then it doesn't meet their needs.

Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 24 Feb 2017 14:32:13 +0100

Hi Barbara,

Then fully agree !

I think the main difference between the “2 groups” that you differentiate is that in the second group the CE needs to support the ability to either being setup as a “bridge” or be able to have a DMZ or to allow ports/protocols forwarding.

Actually, I even think that 5 is part of your “first” group (so together are 1, 2, 4 and 5) and only 3 and 6 are in the second group.

So, according to this, I don’t see the need to have 2 different documents, just un update of the RFC7084 (and as you said, not changing the definition of the terms neither the scope).

Regards,
Jordi

-----Mensaje original-----
De: "STARK, BARBARA H" <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 24 de febrero de 2017, 14:19
Para: "[email-masked]" <[email-masked]>, IPv6 Ops WG <[email-masked]>
Asunto: RE: [v6ops] Requirements for IPv6 routers in various locations

    

    
    
    Barbara

---

From: james woodyatt <[email-masked]>
Date: Fri, 24 Feb 2017 09:50:23 -0800

> Let me throw a question to the working group. One way to approach this is to try to push requirements for all of those markets into one document, which is what I think James is trying to do. Anothe…

For the record, this misrepresents me. I do NOT want to push requirements for all the various IPv6 router deployment scenarios into a single document. I want to see RFC 7084 updated with its focus on residential gateways retained. I do NOT believe that all routers should feature implementations of Home Network Control Protocol (HNCP) services. In <https://www.ietf.org/mail-archive/web/v6ops/current/msg25497.html <https://www.ietf.org/mail-archive/web/v6ops/current/msg25497.html>> I gave my reasoning in support of requiring residential gateways to implement HNCP services, and I don’t see how any of my comments there could be easily misinterpreted as a call to apply this requirement to all IPv6 routers.

If anyone is taking the position that Fred ascribes to me in this comment, I’m not sure who it is.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 27 Feb 2017 16:21:48 +0100

Hi all,

I’ve submitted a new version for this document.

Barbara, after thinking again for several hours on this classification, I’ve the feeling that all those cases have the same requirements as the ones in the original document. Let me explain why. Those 2 cases that need to “export services” (by means of DMZ, virtual host, port/protocol forwarding, etc.), actually will need that only for IPv4 (because the private addresses behind NAT), and this is already supported by all the devices in the market, so we don’t need to have any “new” IPv4 requirements for that.

For IPv6, well, you have GUA, so being all the addresses global, they are always reachable, right? Of course, it will be good that any IPv6 CE has a configurable firewall, and may be enabled by default, but I recall in the original document, there is already text about that, so probably we don’t want to change it.

So according to this, and responding to Fred comments on the decision about one or several documents for different scenarios, I think that leaving out special requirements for data-centers, content-providers, big enterprises, etc., the requirements for a CE “baseline” are the same in all the cases, and the differences are more related to more memory, more interfaces/types/speed, performance, etc.

So, in my opinion, this document is good for most of the residential users, SOHO, SMEs, and probably some degree of medium-to-big organizations, and may be, if we want other scenarios we can either “upgrade” this document to include them, or have other documents that state as “baseline” this document to avoid repeating text. I think the second option is close to what Tim suggested.

So, the new version is:

https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis/

Let me try to summarize the main changes:

1) 6rd and DS-Lite are back SHOULD as in the original document.
2) Requirements for 464XLAT, MAP-E/T, lw4o6 and 6in4 are now completed, and all them are SHOULD, same as 6rd and DS-Lite.
3) Added a section “Usage Scenarios” to clarify what I indicated above.
4) Added, as SHOULD, support for HNCP as a LAN requirement.
5) Added requirement for support of DHCPv6 S46 priority option RFC8026.
6) Added requirement for support of DHCPv4-over-DHCPv6 (DHCP4o6) transport RFC7341.

Comments?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de JORDI PALET MARTINEZ <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 24 de febrero de 2017, 14:32
Para: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] Requirements for IPv6 routers in various locations

    Hi Barbara,
    
    Then fully agree !

    
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: "STARK, BARBARA H" <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: viernes, 24 de febrero de 2017, 14:19
    Para: "[email-masked]" <[email-masked]>, IPv6 Ops WG <[email-masked]>
    Asunto: RE: [v6ops] Requirements for IPv6 routers in various locations

        

        
        
        Barbara

---

From: Yannis Nikolopoulos <[email-masked]>
Date: Tue, 28 Feb 2017 22:29:16 +0200

Hi,

I just don't get why is lw4o6 differentiated from MAP. To me, it does 
not make sense that one is optional and the other two are not. The 
rationale does not help much either

regards,

Yannis

<snip>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 28 Feb 2017 21:42:39 +0100

Hi Yannis,

I’m not sure to understand your point.

Unless I did a mistake while editing the draft, all them are with SHOULD.

Regards,
Jordi

-----Mensaje original-----
De: Yannis Nikolopoulos <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 28 de febrero de 2017, 21:29
Para: <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

    Hi,

    regards,
    
    Yannis

    <snip>