Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

From: [email-masked]
Date: Fri, 22 Nov 2013 10:33:01 -0800 (PST)

A new Request for Comments is now available in online RFC libraries.

        RFC 7084

        Title:      Basic Requirements for IPv6 Customer 
                    Edge Routers 
        Author:     H. Singh, W. Beebee,
                    C. Donley, B. Stark
        Status:     Informational
        Stream:     IETF
        Date:       November 2013
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],
                    [email-masked]
        Pages:      21
        Characters: 46569
        Obsoletes:  RFC 6204

        I-D Tag:    draft-ietf-v6ops-6204bis-12.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7084.txt

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 IP transition
technologies.  Two transition technologies in RFC 5969's IPv6 Rapid
Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack
Lite (DS-Lite) are covered in the document.  The document obsoletes
RFC 6204.

This document is a product of the IPv6 Operations Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 25 Nov 2013 13:54:38 +0100

All,
I can still see it is impossible today to fully comply to this as, IMHO,  the following requirement is impossible to meet (the SHOULD part):
""
WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
           prefix size different from what is given in the hint.  If the
           delegated prefix is too small to address all of its
           interfaces, the IPv6 CE router SHOULD log a system management
           error.  [RFC6177] covers the recommendations for service
           providers for prefix allocation sizes.
""
Checking if a ia_Pd is "too small" is impossible, i.e., what is "too small" ?  What if certain changes are done after initial ia_pd ?  What .... ?

Regs
Carl

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: vrijdag 22 november 2013 19:33
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

        RFC 7084

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 IP transition technologies.  Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document.  The document obsoletes RFC 6204.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Requests for special distribution should be addressed to either the author of the RFC in question, or to [email-masked].  Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.

The RFC Editor Team

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

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 25 Nov 2013 08:35:52 -0500

Carl,

Are you saying that vendors will be unable to determine the number of
[local] interfaces during this initialization step?  As for "what is too
small", is WPD-2 not sufficient in determining that?

   WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
           router the size of the prefix it requires.  If so, it MUST
           ask for a prefix large enough to assign one /64 for each of
           its interfaces, rounded up to the nearest nibble, and SHOULD
           be configurable to ask for more.

As for changes after initial IA_PD, are you concerned about new interfaces
coming up on the box after IPv6 initialization?  If so, should those not be
part of the PD size request upfront? E.g. Ask for /64 for all active and
inactive interfaces.

regards,

Victor K

On Mon, Nov 25, 2013 at 7:54 AM, Wuyts Carl <[email-masked]>wrote:

> All,
> I can still see it is impossible today to fully comply to this as, IMHO,
>  the following requirement is impossible to meet (the SHOULD part):
> ""
> Checking if a ia_Pd is "too small" is impossible, i.e., what is "too
> small" ?  What if certain changes are done after initial ia_pd ?  What ....
> ?
>
> Regs
> Carl
>
>
> 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 IP transition technologies.  Two
> transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4
> Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered
> in the document.  The document obsoletes RFC 6204.
>
> For searching the RFC series, see
> http://www.rfc-editor.org/search/rfc_search.php
> Requests for special distribution should be addressed to either the author
> of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for unlimited
> distribution.
>
>
> The RFC Editor Team

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 25 Nov 2013 14:39:16 +0100

HI Victor,

Indeed, this will not be always known upfront.  Besides that, if you purely want to look at all active interfaces, I believe you will be (for residential market at least) push for a /64 for all deployments, and I don't believe this should be the goal.  After all, many residential scenario's at our customer base are a single LAN from defs....

regs

From: Victor Kuarsingh [mailto:[email-masked]]
Sent: maandag 25 november 2013 14:36
To: Wuyts Carl
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

Carl,

Are you saying that vendors will be unable to determine the number of [local] interfaces during this initialization step?  As for "what is too small", is WPD-2 not sufficient in determining that?

As for changes after initial IA_PD, are you concerned about new interfaces coming up on the box after IPv6 initialization?  If so, should those not be part of the PD size request upfront? E.g. Ask for /64 for all active and inactive interfaces.

regards,

Victor K

On Mon, Nov 25, 2013 at 7:54 AM, Wuyts Carl <[email-masked]<mailto:[email-masked]>> wrote:
All,

Regs
Carl

-----Original Message-----
From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: vrijdag 22 november 2013 19:33
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

        RFC 7084

        Title:      Basic Requirements for IPv6 Customer
                    Edge Routers
        Author:     H. Singh, W. Beebee,
                    C. Donley, B. Stark
        Status:     Informational
        Stream:     IETF
        Date:       November 2013
        Mailbox:    [email-masked]<mailto:[email-masked]>,
                    [email-masked]<mailto:[email-masked]>,
                    [email-masked]<mailto:[email-masked]>,
                    [email-masked]<mailto:[email-masked]>
        Pages:      21
        Characters: 46569
        Obsoletes:  RFC 6204

Requests for special distribution should be addressed to either the author of the RFC in question, or to [email-masked]<mailto:[email-masked]>.  Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.

The RFC Editor Team

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

---

From: [email-masked]
Date: Mon, 25 Nov 2013 09:27:13 -0500

<snip>

> De : Wuyts Carl <[email-masked]>
> Indeed, this will not be always known upfront. 

Carl, could you please give an example where a router doesn't know 
upfront the number of interfaces? Even if some of them could be 
off at some point (Wifi for example), the router usually knows 
the maximum number of local interfaces it can support. 

> Besides that, if you
> purely want to look at all active interfaces, I believe you will be 
> (for residential market at least) push for a /64 for all 
> deployments, and I don?t believe this should be the goal.  After 
> all, many residential scenario?s at our customer base are a single 
> LAN from defs?.

I don't see why this would push /64 in the residential market. 
Most recent routers are expected to have a few interfaces (one 
for public wifi and another for the private lan for example) and 
therefore should hint for a /60 at least. If DHCPv6-PD is supported 
on the LAN side, a hint for /56 or /48 would be expected. 

And a hint is just that, a hint. The operator is free to hand out
larger prefixes. Some operators will hand out a /64 in the 
absence of a hint because of a number of broken old implementations
unable to carve out /64s out of larger prefixes. But beside these, 
/56 or larger is expected to become the standard for residential. 

As a data point, we hand out /56s by default as a cable 
operator and it works fairly well so far. 

/JF

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 25 Nov 2013 15:39:21 +0100

Hi,

A typical CPE has 4 eth ports and wifi, all joined together as ... the LAN intf, hence 1 interface it is.  You do not hand out different prefixes to wired and wireless.  In fact, you can of course, but this would lead to routed traffic between wired and wireless, which cannot be the target I'd say.
Potentially, you could have a separate hotspot/public wifi, even more than one potentially,  although for sure not always used, and very often v4-only, hence no real need today for ipv6 prefix today.

We're deploying in managed CPE, so the hint will for sure not change anything.  I agree it is also "just" a hint, but the req in the RFC says you SHOULD flag "too small" and it's exactly that part which is not ok, not the fact that you should sent a hint or anything.

Today, our customers hand out anything between 48 and 64, and size NOT depending on "too big or too small".

And I do get a /56 @ home, so works smooth here too, but the choice of /56 is not depending small/big number of physical intfs.

Regs
Carl

From: [email-masked] [mailto:[email-masked]]
Sent: maandag 25 november 2013 15:27
To: Wuyts Carl
Cc: [email-masked]; Victor Kuarsingh
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

<snip>

> De : Wuyts Carl <[email-masked]<mailto:[email-masked]>>

> deployments, and I don't believe this should be the goal.  After
> all, many residential scenario's at our customer base are a single
> LAN from defs....

/JF

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Nov 2013 15:48:20 +0100

Carl,

> A typical CPE has 4 eth ports and wifi, all joined together as … the LAN intf, hence 1 interface it is.  You do not hand out different prefixes to wired and wireless.  In fact, you can of course, but this would lead to routed traffic between wired and wireless, which cannot be the target I’d say.
> We’re deploying in managed CPE, so the hint will for sure not change anything.  I agree it is also “just” a hint, but the req in the RFC says you SHOULD flag “too small” and it’s exactly that part which is not ok, not the fact that you should sent a hint or anything. 
> 
> Today, our customers hand out anything between 48 and 64, and size NOT depending on “too big or too small”. 
> 

the hint is a MAY. you'd be perfectly fine not including it.
the hint is largely there to give an indication to the server to give the same prefix back as it delegated in a previous session.

cheers,
Ole

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 25 Nov 2013 09:57:10 -0500

On Mon, Nov 25, 2013 at 9:39 AM, Wuyts Carl <[email-masked]>wrote:

> Hi,
>
>
>
> A typical CPE has 4 eth ports and wifi, all joined together as … the LAN
> intf, hence *1 interface* it is.  You do not hand out different prefixes
> to wired and wireless.  In fact, you can of course, but this would lead to
> routed traffic
>

Carl,

In your case above, I am not sure if the Eth ports you are referring to are
separate logical interfaces which are just bridged together or if they are
just switch ports that connect back to a single logical interface.
 Notwithstanding this, could you not consider all logical interfaces
(regardless if they are bridged day-1) as separate for the purposes of
asking for IPv6 PD space?

Lets assume that you have 4 eth ports, and standard WiFi interface and a
Guest WiFi.  This sounds like 6x [potential] interfaces, of which you may
only be using 1-2 for now [say LAN/WiFi is one, and Guest WiFi is two).  If
you ask for IPv6 PD space for all of the potential interfaces, rounded up
to the nearest nibble, you would grab a ::/60.

So in the beginning, you only configure 2 ::/64s for the interfaces you
fire up.  If you expand this and/or break out the function later, then you
use more (out of the ::/60).  If you only got a ::/62 or ::/64 from the
operator, then you log an error (right)?  If you get a ::/60 or ::/56 you
are ok (right)?

regards,

Victor K

>
>
>
>
> Regs
>
> Carl
>
>
>
> *From:* [email-masked] [mailto:
> [email-masked]]
> *Sent:* maandag 25 november 2013 15:27
> *To:* Wuyts Carl
> *Cc:* [email-masked]; Victor Kuarsingh
> *Subject:* Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer
> Edge Routers
>
>
>
> <snip>
>
> > deployments, and I don’t believe this should be the goal.  After
> > all, many residential scenario’s at our customer base are a single
> > LAN from defs….
>

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 25 Nov 2013 15:53:40 +0100

Hi Ole,

I've seen the MAY and SHOULD etc, I just think it is a silly requirement, hence should better not be present, so just leave it out (hint can stay in perfectly)
It in fact leads to customers asking us "too small-checking" in tenders/rfp/..., so as of that moment, you have to start explaining that this is not possible, there is AND should be NO link between them.  You should not put up these reqs to the CPEs at all as they make no sense.  Everyone will translate this their own way.  I've talked to someone not too long ago, claiming that /60 is too small for him/his network, although I would highly doubt he has a CPE with 16 physical intfs...

Regs
Carl

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: maandag 25 november 2013 15:48
To: Wuyts Carl
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

Carl,

cheers,
Ole

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 25 Nov 2013 16:03:32 +0100

Hi Victor,

Agree.  I do always recommend our customers to assign /56.  This doesn't mean it is always being deployed like this of course, we have single /64s as well.  But this is better for the sake of future proof and leaves some room for expansion without having to fiddle in the back-end to aggregation etc.
The point I want to make is that the req of checking "too small" serves no goal, as nearly all CPE devices have a similar set of interfaces, of which some are used separately, mostly not, some have public wifi, mostly not, etc.  It just makes customers asking questions on it, as they base themselves upon this RFC to send their reqs to CPE vendors.  Moreover, too small (too big too ??) is too much subject of interpretation.

Regs
Carl

From: Victor Kuarsingh [mailto:[email-masked]]
Sent: maandag 25 november 2013 15:57
To: Wuyts Carl
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

On Mon, Nov 25, 2013 at 9:39 AM, Wuyts Carl <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

A typical CPE has 4 eth ports and wifi, all joined together as ... the LAN intf, hence 1 interface it is.  You do not hand out different prefixes to wired and wireless.  In fact, you can of course, but this would lead to routed traffic

Carl,

In your case above, I am not sure if the Eth ports you are referring to are separate logical interfaces which are just bridged together or if they are just switch ports that connect back to a single logical interface.  Notwithstanding this, could you not consider all logical interfaces (regardless if they are bridged day-1) as separate for the purposes of asking for IPv6 PD space?

Lets assume that you have 4 eth ports, and standard WiFi interface and a Guest WiFi.  This sounds like 6x [potential] interfaces, of which you may only be using 1-2 for now [say LAN/WiFi is one, and Guest WiFi is two).  If you ask for IPv6 PD space for all of the potential interfaces, rounded up to the nearest nibble, you would grab a ::/60.

So in the beginning, you only configure 2 ::/64s for the interfaces you fire up.  If you expand this and/or break out the function later, then you use more (out of the ::/60).  If you only got a ::/62 or ::/64 from the operator, then you log an error (right)?  If you get a ::/60 or ::/56 you are ok (right)?

regards,

Victor K

Regs
Carl

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: maandag 25 november 2013 15:27
To: Wuyts Carl
Cc: [email-masked]<mailto:[email-masked]>; Victor Kuarsingh
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

<snip>

/JF

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Nov 2013 18:51:41 +0100

Hi,

> We're deploying in managed CPE, so the hint will for sure not change anything.  I agree it is also "just" a hint, but the req in the RFC says you SHOULD flag "too small" and it's exactly that part…

I really can't see the point of this.

Your CPE is configured to have 2 different LAN zones, and 1 WiFi zone.

IETF says "a /64 per routed interface".  So you count 1..2..3 and request
a /62 or /60.

The ISP gives you a /63.  You count again "1..2...oops".

You log "to number all (3) interfaces a /62 has been requested by DHCP-PD
and only a /63 has been delegated.  Interface 3 (WiFi) will not receive
an IPv6 address, we're sorry".

Now which is the step that you are unable to do?

(Maybe I'm daft, or it's because I've never worked for a mass marked CPE
producer, but this really seems straightforward and easy to implement to
me...)

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: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Nov 2013 08:31:34 +1300

> The point I want to make is that the req of checking "too small" serves no goal, as nearly all CPE devices have a similar set of interfaces, of which some are used separately, mostly not, some have…

If I'm implementing a device and the spec includes a SHOULD, I will read the
definition of SHOULD:

"SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

In the case in point, if I am unable to determine whether the
delegated prefix is too "small" to address all interfaces,
that is clearly a valid reason to ignore the requirement.
Therefore, I don't see this as a formal defect in WPD-3.

I think it's true that in many cases, the CPE will be unable to
determine whether the prefix is too "small". Also, if there happens
to be a subsidiary router hanging off one of the interfaces, it might
want a whole bunch of prefixes, and the CPE router can't possibly
know that in advance.

Also, "small" in this case turns out to mean "long".

WPD-3 could have been better phrased, but since product development
managers have never met a SHOULD that they couldn't ignore,
I doubt that it really matters.

    Brian

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 26 Nov 2013 07:51:53 +0100

Hi Brian,

I Agree on the SHOULD statement, no issue of "not complying" with the RFC due to this.  However, as far as I know, SHOULD means "support it unless a good reason exists to not do this".  As you state below, the good reason is there "you don't know", but it's not a pleasant thing having to convince customers of this over and over.  As I've said: this part of that req has no added value at all, hence should not be present.

Regs
Carl

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: maandag 25 november 2013 20:32
To: Wuyts Carl
Cc: Victor Kuarsingh; [email-masked]
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

> The point I want to make is that the req of checking "too small" serves no goal, as nearly all CPE devices have a similar set of interfaces, of which some are used separately, mostly not, some have…

If I'm implementing a device and the spec includes a SHOULD, I will read the definition of SHOULD:

In the case in point, if I am unable to determine whether the delegated prefix is too "small" to address all interfaces, that is clearly a valid reason to ignore the requirement.
Therefore, I don't see this as a formal defect in WPD-3.

I think it's true that in many cases, the CPE will be unable to determine whether the prefix is too "small". Also, if there happens to be a subsidiary router hanging off one of the interfaces, it might want a whole bunch of prefixes, and the CPE router can't possibly know that in advance.

WPD-3 could have been better phrased, but since product development managers have never met a SHOULD that they couldn't ignore, I doubt that it really matters.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 26 Nov 2013 11:36:08 +0100

Carl,

> I Agree on the SHOULD statement, no issue of "not complying" with the RFC due to this.  However, as far as I know, SHOULD means "support it unless a good reason exists to not do this".  As you stat…

at some point in time you can detect when you've run out of prefixes to assign. be that to local interfaces or via a homenet control protocol.

is the confusion about timing? WPD-3 clearly allows the logging to happen at any point in time, independent of the prefix delegation state machine. there is no expectation that the CPE indicates this to the delegating router in anyhow.

cheers,
Ole

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 26 Nov 2013 15:58:20 +0000

The idea is that a unique /64 is given to each of the LAN interfaces.  If
there's not enough delegated address space, a system management error
SHOULD be logged (the reason it's a SHOULD is that some boxes may not have
a web-interface/console to log to).  The document doesn't cover the case
where you add LAN interfaces to the box - but you could, in principle,
follow the same logic there as well - and log an error message.

- Wes

On 11/25/13 7:54 AM, "Wuyts Carl" <[email-masked]> wrote:

>small" ?  What if certain changes are done after initial ia_pd ?  What
>.... ?
>
>Regs
>Carl
>
>
>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 IP transition
>Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite
>(DS-Lite) are covered in the document.  The document obsoletes RFC 6204.
>