Subject: [v6ops] RFC6204bis-07

From: Wuyts Carl <[email-masked]>
Date: Thu, 15 Mar 2012 11:30:32 +0100

All,

One which sort of slipped through my review is the following (although I might have commented on this one before):
""
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.

""
The issue I can see is with "... if the delegated prefix is too small to address all of its interfaces ...".  Too small, what is that exactly ?  I don't think the CPE should first inspect all of its LAN interfaces (count them) and then judge whether or not the PD is "large enough".  Someone could even reserve something from the pd for the loop, adding an extra prefix, should this one be counted too in this case ?  What with configuration changes ?  What if the customer expects to have multiple prefixes on each or some LAN intfs, should the CPE have some multiplier function to calculate ?  Moreover, it must also check the pd-exclude, if present.
Isn't this all going a bit too far ?
What about the result when it is too small ?  You hand out what you have ? or you don't hand out anything, so just logging ?  but the logging is no MUST, hence no-one might notice, apart from the end-user who can or cannot browse the web ?

Regs
Carl

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 15 Mar 2012 06:36:44 -0500

/64 is too small because the SLAAC addressing can't be supported on the
CE router LAN.   Thereafter,  with hierarchical sub-delegation, the CE
router splits the PD based on the number of LAN subnets  rounded up to
the nearest power of two.   Further, the specification does not bother
with LAN physical ports or virtual network interfaces such as a
loopback.  The specification uses the term of "interface"  that is
assigned a subnet.  It is ridiculously simple math.  For example,  if an
SP gave the CE a /63 and if the CE needs two subnets, the PD is too
small for hierarchical sub-delegation.

The MUST on the system management error looks ok to me.  If the CE can't
sub-delegate the PD in the LAN, the CE is a brick for IPv6 services.. 

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wuyts Carl
Sent: Thursday, March 15, 2012 6:31 AM
To: [email-masked]
Subject: [v6ops] RFC6204bis-07

All,

One which sort of slipped through my review is the following (although I
might have commented on this one before):

""

           error.

""

The issue I can see is with "... if the delegated prefix is too small to
address all of its interfaces ...".  Too small, what is that exactly ?
I don't think the CPE should first inspect all of its LAN interfaces
(count them) and then judge whether or not the PD is "large enough".
Someone could even reserve something from the pd for the loop, adding an
extra prefix, should this one be counted too in this case ?  What with
configuration changes ?  What if the customer expects to have multiple
prefixes on each or some LAN intfs, should the CPE have some multiplier
function to calculate ?  Moreover, it must also check the pd-exclude, if
present.

What about the result when it is too small ?  You hand out what you have
? or you don't hand out anything, so just logging ?  but the logging is
no MUST, hence no-one might notice, apart from the end-user who can or
cannot browse the web ?

Regs

Carl

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 15 Mar 2012 12:50:20 +0100

As often, I do not agree, sorry.

I agree something better than /64 should be assigned (no doubt about that one), and I also always recommend this to our customers.  But... /64 is enough to serve a basic residential scenario, where the end-user just had 1 subnet in the home, in fact, we have some of our customers deploying it like this, so I can confirm: it works.
We can cope with any value, so /64, /63, /62, /56,  /48 or whatever but we do not count first how many interfaces must be served.  You say "the CE needs 2 subnets". But how does the CPE knows (What part do you inform on this ?  some parameter in the Router Adv daemon ?  The DHCPv6 implementation or ... ?  Maybe the end-user (IF he is allowed to configure anything, which is very often not the case) would like 16 subnets, but only gets an /63, then what ??  What if a user adds another LAN interface/subnet afterwards (all of a sudden the pd becomes too "small")?

I think (again) the small residential CPE is not considered in this.  And again, some binding between things is being done (# of LANs to be counted vs received pd).  FYI, we're selling managed CPEs, so the issue itself will most likely not show up, unless maybe during some lab-testing.  Maybe I'm overlooking something, but personally I believe that reqs like this don't serve any real purpose, they don't bring real added value, just increase CPE complexity.

So the WPD-3 is ok wrt hinting something and getting something different back, but the "too small + logging" stuff should be left out or potentially "degraded" to a MAY.

Regs
Carl

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: donderdag 15 maart 2012 12:37
To: Wuyts Carl; [email-masked]
Subject: RE: [v6ops] RFC6204bis-07

/64 is too small because the SLAAC addressing can't be supported on the CE router LAN.   Thereafter,  with hierarchical sub-delegation, the CE router splits the PD based on the number of LAN subnets  rounded up to the nearest power of two.   Further, the specification does not bother with LAN physical ports or virtual network interfaces such as a loopback.  The specification uses the term of "interface"  that is assigned a subnet.  It is ridiculously simple math.  For example,  if an SP gave the CE a /63 and if the CE needs two subnets, the PD is too small for hierarchical sub-delegation.

The MUST on the system management error looks ok to me.  If the CE can't sub-delegate the PD in the LAN, the CE is a brick for IPv6 services..

Hemant

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Thursday, March 15, 2012 6:31 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [v6ops] RFC6204bis-07

All,

""

Regs
Carl

---

From: Ray Hunter <[email-masked]>
Date: Thu, 15 Mar 2012 13:49:01 +0100

Hermant, IMHO the root cause of the prefix size "too small" problem is 
that the operator of the DHCPv6 PD delegating router has not adhered to 
BCP RFC6177 Section 5 Summary.

WPD-3 of RFC6204bis suggests logging a system management error, but I 
don't see anything in RFC6204bis or RFC3633 or RFC3315 that would allow 
a CE manufacturer/end user who is operating the requesting router to be 
able to signal back to the delegating router (where the root cause of 
the problem lies) that the prefix was too small (either via a DHCPv6 PD 
status code such as "PREFIX_TOO_SMALL", or any other standard logging 
mechanism).

Local system management logging would not seem to address the root 
cause, and would seem to potentially leave the end user/ CE manufacturer 
in no man's land.

To address the root cause, I'd like to propose RFC6024bis refer to 
RFC6177 as a normative reference.

Firstly, to attempt to lower the likelihood of this problem ever 
occurring in production, and secondly if it does occur, to provide a 
good indication of how to solve it.

regards.
RayH

Hemant Singh (shemant) wrote:
>
> /64 is too small because the SLAAC addressing can't be supported on 
> the CE router LAN.   Thereafter,  with hierarchical sub-delegation, 
> the CE router splits the PD based on the number of LAN subnets 
>  rounded up to the nearest power of two.   Further, the specification 
> does not bother with LAN physical ports or virtual network interfaces 
> such as a loopback.  The specification uses the term of "interface" 
>  that is assigned a subnet.  It is ridiculously simple math.  For 
> example,  if an SP gave the CE a /63 and if the CE needs two subnets, 
> the PD is too small for hierarchical sub-delegation.
>
> The MUST on the system management error looks ok to me.  If the CE 
> can't sub-delegate the PD in the LAN, the CE is a brick for IPv6 
> services..
>
> Hemant
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Wuyts Carl
> *Sent:* Thursday, March 15, 2012 6:31 AM
> *To:* [email-masked]
> *Subject:* [v6ops] RFC6204bis-07
>
> All,
>
> One which sort of slipped through my review is the following (although 
> I might have commented on this one before):
>
> ""
>
> The issue I can see is with "... if the delegated prefix is too small 
> to address all of its interfaces ...".  Too small, what is that 
> exactly ?  I don't think the CPE should first inspect all of its LAN 
> interfaces (count them) and then judge whether or not the PD is "large 
> enough".  Someone could even reserve something from the pd for the 
> loop, adding an extra prefix, should this one be counted too in this 
> case ?  What with configuration changes ?  What if the customer 
> expects to have multiple prefixes on each or some LAN intfs, should 
> the CPE have some multiplier function to calculate ?  Moreover, it 
> must also check the pd-exclude, if present.
>
> What about the result when it is too small ?  You hand out what you 
> have ? or you don't hand out anything, so just logging ?  but the 
> logging is no MUST, hence no-one might notice, apart from the end-user 
> who can or cannot browse the web ?
>
> Regs
>
> Carl
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 15 Mar 2012 08:44:18 -0500

Carl,

It's up to the CE router software design to do what regarding the error
message.   You decided to count the physical ports on the CE router LAN
but that approach is not very sound because the LAN ports could be
routed, switched, or bridged ports.    I am working at the subnet
configuration of a network interface.   Whenever the CE router
(automatically or manual configuration) is configured with a subnet for
the LAN interface, if the WAN- acquired PD does not allow the LAN subnet
to be configured, flag an error on the CE router.   For your /64 PD
acquired by the WAN to use on one LAN port, your CE router won't raise
an error if the WAN is unnumbered.    WPD-3 is fine as a requirement
because the rfc6204bis is a requirements document, because again, we did
not want the CE to be a brick silently. 

Regards,

Hemant

From: Wuyts Carl [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 7:50 AM
To: Hemant Singh (shemant); [email-masked]
Subject: RE: [v6ops] RFC6204bis-07

I agree something better than /64 should be assigned (no doubt about
that one), and I also always recommend this to our customers.  But...
/64 is enough to serve a basic residential scenario, where the end-user
just had 1 subnet in the home, in fact, we have some of our customers
deploying it like this, so I can confirm: it works.

We can cope with any value, so /64, /63, /62, /56,  /48 or whatever but
we do not count first how many interfaces must be served.  You say "the
CE needs 2 subnets". But how does the CPE knows (What part do you inform
on this ?  some parameter in the Router Adv daemon ?  The DHCPv6
implementation or ... ?  Maybe the end-user (IF he is allowed to
configure anything, which is very often not the case) would like 16
subnets, but only gets an /63, then what ??  What if a user adds another
LAN interface/subnet afterwards (all of a sudden the pd becomes too
"small")?

I think (again) the small residential CPE is not considered in this.
And again, some binding between things is being done (# of LANs to be
counted vs received pd).  FYI, we're selling managed CPEs, so the issue
itself will most likely not show up, unless maybe during some
lab-testing.  Maybe I'm overlooking something, but personally I believe
that reqs like this don't serve any real purpose, they don't bring real
added value, just increase CPE complexity.

So the WPD-3 is ok wrt hinting something and getting something different
back, but the "too small + logging" stuff should be left out or
potentially "degraded" to a MAY.

Regs

Carl

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 15 Mar 2012 15:30:08 +0100

Well, I was not really counting physical ports, but more IP LAN intf, i.e. subnets, on the LAN.
Anyway, I don't think we will hit this one anyway, as we allow flexible configuration of /64 sub-netting anyway.  The "too small" would only be hit in case you would start from the first available /64, but this is not mandatory, so probably kind of different on our CPEs.
Thx for the updates

Regs
Carl

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: donderdag 15 maart 2012 14:44
To: Wuyts Carl; [email-masked]
Subject: RE: [v6ops] RFC6204bis-07

Carl,

It's up to the CE router software design to do what regarding the error message.   You decided to count the physical ports on the CE router LAN but that approach is not very sound because the LAN ports could be routed, switched, or bridged ports.    I am working at the subnet configuration of a network interface.   Whenever the CE router (automatically or manual configuration) is configured with a subnet for the LAN interface, if the WAN- acquired PD does not allow the LAN subnet to be configured, flag an error on the CE router.   For your /64 PD acquired by the WAN to use on one LAN port, your CE router won't raise an error if the WAN is unnumbered.    WPD-3 is fine as a requirement because the rfc6204bis is a requirements document, because again, we did not want the CE to be a brick silently.

Regards,

Hemant

From: Wuyts Carl [mailto:[email-masked]]
Sent: Thursday, March 15, 2012 7:50 AM
To: Hemant Singh (shemant); [email-masked]<mailto:[email-masked]>
Subject: RE: [v6ops] RFC6204bis-07

Regs
Carl

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 15 Mar 2012 09:34:06 -0500

Ray,

From: Ray Hunter [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 8:49 AM
To: Hemant Singh (shemant)
Cc: Wuyts Carl; [email-masked]
Subject: Re: Re: [v6ops] RFC6204bis-07

that the operator of the DHCPv6 PD delegating router has not adhered to
BCP >RFC6177 Section 5 Summary.

Not  quite.  Carl just reported he their CE routers deployed with a /64.
RFC 6177 does not recommend a size but does relax the old /48 with a /56
recommendation. 

don't see anything in RFC6204bis or RFC3633 or RFC3315 that would allow
a CE >manufacturer/end user who is operating the requesting router to be
able to signal back to the delegating router (where the root cause of
the >problem lies) that the prefix was too small (either via a DHCPv6 PD
status code such as "PREFIX_TOO_SMALL", or any other standard logging
>mechanism).

That is why the CE router has to log an error.  How the CE does that is
out of scope of the document.   Some CE router can be a sophisticated
SOHO router that supports syslog error messages while another cheap
retail router uses an LED to signal the error.  Or use a different color
with an existing LED.   Also if the CE router supports a web UI, the UI
also displays the error. 

in no >man's land. 

With the error, the user can at least call the SP to report the issue.
Sure, calling the SP is not a good option, but what can the CE do if the
protocols do not support reporting such a failure.    At this point I am
not sure if the protocols can even do anything about the situation
because one does not know when the user provisions his/her last subnet
that goes one over the PD allocation which could be days after the PD
was acquired with DHCPv6.  

But Carl already has a use case of a /64.   I am not for or against
adding RFC 6177.   Others in the WG can comment. 

Regards,

Hemant

---

From: Ole Trøan <[email-masked]>
Date: Thu, 15 Mar 2012 09:56:03 -0700

Carl,

WPD-3 does two things. it states that if the CPE uses a hint, then it must be prepared to accept a different size than what it asked for. secondly it states that if address block delegated is too small for the sites needs, you are in undefined territory.

can we do better than "undefined" for that latter case? I'm not sure, given the protocol we have.

cheers,
Ole

On Mar 15, 2012, at 3:30 , Wuyts Carl wrote:

> “”
> “”
> The issue I can see is with “… if the delegated prefix is too small to address all of its interfaces …”.  Too small, what is that exactly ?  I don’t think the CPE should first inspect all of its LAN interfaces (count them) and then judge whether or not the PD is “large enough”.  Someone could even reserve something from the pd for the loop, adding an extra prefix, should this one be counted too in this case ?  What with configuration changes ?  What if the customer expects to have multiple prefixes on each or some LAN intfs, should the CPE have some multiplier function to calculate ?  Moreover, it must also check the pd-exclude, if present.
> Isn’t this all going a bit too far ?
> What about the result when it is too small ?  You hand out what you have ? or you don’t hand out anything, so just logging ?  but the logging is no MUST, hence no-one might notice, apart from the end-user who can or cannot browse the web ?
>  
> Regs
> Carl
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 15 Mar 2012 20:01:08 +0100

Ole,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole
> Troan
> Sent: Thursday, March 15, 2012 5:56 PM
> To: Wuyts Carl
> Cc: [email-masked]
> Subject: Re: [v6ops] RFC6204bis-07
> 
> Carl,
> 
> WPD-3 does two things. it states that if the CPE uses a hint, then it must be prepared
> to accept a different size than what it asked for.

Does it make sense repeat what's already written in Section 11.2 of RFC3633? Given that
6204bis requires compliance to RFC3633.

   If the requesting router includes an IA_PD Prefix option in the IA_PD
   option in its Solicit message, the delegating router MAY choose to
   use the information in that option to select the prefix(es) or prefix
   size to be delegated to the requesting router.

> Ole

Cheers,
Ales

---

From: Ray Hunter <[email-masked]>
Date: Fri, 16 Mar 2012 09:10:30 +0100

Requirement L2 requires assignment of a /64 to each LAN interface and is 
a MUST. Those addresses may be obtained by WPD-1 (again DHCPv6 PD 
support is a MUST). The "too small" error of DHCPv6 PD is an issue that 
can completely "brick" the CE router to use your own term. That to me is 
an important issue. As a consumer, I could buy a fully compliant 
RFC6204bis-07 router and connect it to a fully compliant RFC6204bis-07 
Service Provider and it will not function at all. I find that very odd.

BCP 157 (RFC 6177) says "it should be easy for an end site to obtain 
address space to
         number multiple subnets (i.e., a block larger than a single /64)
         and to support reasonable growth projections over long time
         periods (e.g., a decade or more)."

You are correct that the BCP doesn't say fixed /48 or /56 any more, nor 
define "long time periods".

But a decade is very much longer than any PD timers I know of.

And allocating a single /64 per end site is clearly not Best Current 
Practice, as that does not support numbering of multiple subnets on the 
end site.

Following IMVHO: We go into great detail on address assignment in 
6204bis, but miss the obvious statement that a CE device needs to be 
delegated enough addresses so that it can assign a /64 per LAN in order 
for 6204bis to work as designed. v6ops WG shouldn't encourage SP's who 
ignore BCP (by assigning a single /64 to an end site) to continue such 
practices without a very good reason, and that reason has not been 
presented. I think RFC6177 is required for 6204bis to work as designed, 
and is thus normative.

Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative reference.

regards,
RayH

Hemant Singh (shemant) wrote:
>
> Ray,
>
> *From:* Ray Hunter [mailto:[email-masked]]
> *Sent:* Thursday, March 15, 2012 8:49 AM
> *To:* Hemant Singh (shemant)
> *Cc:* Wuyts Carl; [email-masked]
> *Subject:* Re: Re: [v6ops] RFC6204bis-07
>
> that the operator of the DHCPv6 PD delegating router has not adhered 
> to BCP >RFC6177 Section 5 Summary.
>
> Not  quite.  Carl just reported he their CE routers deployed with a 
> /64.    RFC 6177 does not recommend a size but does relax the old /48 
> with a /56 recommendation.
>
>
> don't see anything in RFC6204bis or RFC3633 or RFC3315 that would 
> allow a CE >manufacturer/end user who is operating the requesting 
> router to be able to signal back to the delegating router (where the 
> root cause of the >problem lies) that the prefix was too small (either 
> via a DHCPv6 PD status code such as "PREFIX_TOO_SMALL", or any other 
> standard logging >mechanism).
>
> That is why the CE router has to log an error.  How the CE does that 
> is out of scope of the document.   Some CE router can be a 
> sophisticated SOHO router that supports syslog error messages while 
> another cheap retail router uses an LED to signal the error.  Or use a 
> different color with an existing LED.   Also if the CE router supports 
> a web UI, the UI also displays the error.
>
>
> cause, and would seem to potentially leave the end user/ CE 
> manufacturer in no >man's land.
>
> With the error, the user can at least call the SP to report the 
> issue.   Sure, calling the SP is not a good option, but what can the 
> CE do if the protocols do not support reporting such a failure.    At 
> this point I am not sure if the protocols can even do anything about 
> the situation because one does not know when the user provisions 
> his/her last subnet that goes one over the PD allocation which could 
> be days after the PD was acquired with DHCPv6.
>
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 16 Mar 2012 07:01:21 -0500

Ray,

Sent: Friday, March 16, 2012 4:11 AM

6204bis, but miss the obvious statement that a CE device needs to be
delegated enough >addresses so that it can assign a /64 per LAN in order
for 6204bis to work as designed. v6ops WG shouldn't encourage SP's who
ignore BCP (by assigning a >single /64 to an end site) to continue such
practices without a very good >reason, and that reason has not been
presented. I think RFC6177 is required >for 6204bis to work as designed,
and is thus normative.

OK.  I agree using a /64 in the LAN is something the IETF should
discourage.  

>Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative
reference.

Taken.  Will add the normative reference.

Thanks much,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 16 Mar 2012 07:11:19 -0500

>Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative
reference.

RFC 6177 seems like a good candidate to have made it to the ipv6 node
reqs document in RFC 6434.  After all, an SP delegating router/dhcpv6
server is configured for prefix allocation and the configuration of such
nodes for a prefix can use guidance from RFC 6177.

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 16 Mar 2012 21:15:28 +0000

No. IMO this is not a good thing to do. This is a CE router spec. It is not, nor will it ever be, an access network spec.

My interpretation of this suggestion is "well, maybe if we require the world around the CE router to be perfect, then the CE router won't ever be faced with imperfections." What a lovely world that would be. And thoroughly unrealistic. The CE router and the IETF have zero control over the access network that the CE router finds itself in. The goal needs to be to make the CE router reasonably robust, to handle a variety of situations. My tea leaf reading says that no matter how hard or how often the IETF tries to dictate to access network providers what the IETF thinks providers should do, there will always be those providers who ignore the IETF. Live with it. Deal with it. And the CE router needs to deal with it, too. That's reality.

Again. This is a CE router spec. The proposal does not place any additional requirement on the CE router. A normative reference for the CE router to ensure that the access network always provides something bigger than a /64  is meaningless and useless.
Barbara

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Friday, March 16, 2012 8:01 AM
To: Ray Hunter
Cc: [email-masked]
Subject: Re: [v6ops] RFC6204bis-07

Ray,

From: Ray Hunter [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, March 16, 2012 4:11 AM
To: Hemant Singh (shemant)
Cc: Wuyts Carl; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] RFC6204bis-07

>Following IMVHO: We go into great detail on address assignment in 6204bis, but miss the obvious statement that a CE device needs to be delegated enough >addresses so that it can assign a /64 per LAN in order for 6204bis to work as designed. v6ops WG shouldn't encourage SP's who ignore BCP (by assigning a >single /64 to an end site) to continue such practices without a very good >reason, and that reason has not been presented. I think RFC6177 is required >for 6204bis to work as designed, and is thus normative.
OK.  I agree using a /64 in the LAN is something the IETF should discourage.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 16 Mar 2012 16:42:33 -0500

Does the new text work because the IETF does want to discourage a /64
delegated prefix to the CE and Ray would like RFC 6177 referenced?  I
personally do not like adding a specific prefix length to the bullet but
then how else is the IETF going to discourage CE routers using a /64?  

WPD-4:  The IPv6 CE router MUST be prepared to accept a delegated

           interfaces or not shorter than a /64, the IPv6 CE router 

           SHOULD log a system management error.  [RFC6177]  provides 

           guidance for a shorter than /64 delegated prefix on the CE
router.

Hemant

From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Friday, March 16, 2012 5:15 PM
To: Hemant Singh (shemant); Ray Hunter
Cc: [email-masked]
Subject: RE: [v6ops] RFC6204bis-07

No. IMO this is not a good thing to do. This is a CE router spec. It is
not, nor will it ever be, an access network spec. 

My interpretation of this suggestion is "well, maybe if we require the
world around the CE router to be perfect, then the CE router won't ever
be faced with imperfections." What a lovely world that would be. And
thoroughly unrealistic. The CE router and the IETF have zero control
over the access network that the CE router finds itself in. The goal
needs to be to make the CE router reasonably robust, to handle a variety
of situations. My tea leaf reading says that no matter how hard or how
often the IETF tries to dictate to access network providers what the
IETF thinks providers should do, there will always be those providers
who ignore the IETF. Live with it. Deal with it. And the CE router needs
to deal with it, too. That's reality.

Again. This is a CE router spec. The proposal does not place any
additional requirement on the CE router. A normative reference for the
CE router to ensure that the access network always provides something
bigger than a /64  is meaningless and useless.

Barbara

---

From: Ray Hunter <[email-masked]>
Date: Sat, 17 Mar 2012 20:25:00 +0100

Hemant: your suggested text works fine for me. Many thanks.

After reading Carl's and Barbara's comments on this requirement 
carefully, I've also tried to draft alternative text myself for further 
consideration:

            prefix size different from that given in the hint.

            If the delegated prefix is too small to address all of its

            interfaces, or the prefix is not shorter than a /64, the 
IPv6 CE router * *

* *SHOULD assign a separate /64 from its delegated prefix(es) to each of 
as many of its LAN interfaces as possible,

            and SHOULD log a system management error.

            Best Current Practice for IPv6 Address Assignment to End 
Sites is provided in BCP 157 (RFC6177) [RFC6177].

Idea being that the requirement defines some positive behavior to 
perform to make the best of this situation (Barbara's "just deal with 
it" comment), that can be tested for compliance (Carl's comment that no 
behavior was defined that could be compliance tested and thus this was a 
redundant requirement), still deprecates single /64 (my concern) without 
over-stepping what is already generally agreed in BCP157 (Barbara's "A 
normative reference for the CE router to ensure that the access network 
always provides something bigger than a /64  is meaningless and 
useless."), prevents SLAAC being broken by assignment of longer than /64 
prefixes on the LAN or some other prefix sharing hack (a lot of people's 
concern), and does raise an error (your suggestion to do something to 
alert a human to the undesirable situation) .

Feel free to improve, or keep your original proposed text.

Thanks,
RayH

Hemant Singh (shemant) wrote:
> personally do not like adding a specific prefix length to the bullet 
> but then how else is the IETF going to discourage CE routers using a 
> /64? 0
>
>            interfaces or *not shorter than a /64*, the IPv6 CE router
>
> *From:* STARK, BARBARA H [mailto:[email-masked]]
> *Sent:* Friday, March 16, 2012 5:15 PM
> *To:* Hemant Singh (shemant); Ray Hunter
> *Cc:* [email-masked]
> *Subject:* RE: [v6ops] RFC6204bis-07
>
> No. IMO this is not a good thing to do. This is a CE router spec. It 
> is not, nor will it ever be, an access network spec.
>
> world around the CE router to be perfect, then the CE router won't 
> ever be faced with imperfections." What a lovely world that would be. 
> And thoroughly unrealistic. The CE router and the IETF have zero 
> control over the access network that the CE router finds itself in. 
> The goal needs to be to make the CE router reasonably robust, to 
> handle a variety of situations. My tea leaf reading says that no 
> matter how hard or how often the IETF tries to dictate to access 
> network providers what the IETF thinks providers should do, there will 
> always be those providers who ignore the IETF. Live with it. Deal with 
> it. And the CE router needs to deal with it, too. That's reality.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 17 Mar 2012 17:01:59 -0500

Ray,

A bullet above the bullet that includes "too small" actually defines
what is too small.  The other bullet is shown below. 

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.

Thus we can leave the bullet with "too small" as is and add the
reference to RFC 6177 to the bullet above.  The bullet numbers have
shifted around.  Check either of rfc6204 or RFC6204bis-07 at 

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-07

Thanks,

Hemant

From: Ray Hunter [mailto:[email-masked]] 
Sent: Saturday, March 17, 2012 3:25 PM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; [email-masked] WG; Wuyts Carl
Subject: Re: [v6ops] RFC6204bis-07

           interfaces, or the prefix is not shorter than a /64, the IPv6
CE router 

           SHOULD assign a separate /64 from its delegated prefix(es) to
each of as many of its LAN interfaces as possible,

Thanks,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Sat, 17 Mar 2012 23:29:22 +0100

OK to be clear, would that mean the following delta to 6204-07?

 >new   Best Current Practice for IPv6 Address Assignment to End Sites is
 >new   provided in BCP 157 (RFC6177) [RFC6177].

  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

 >new   SHOULD assign a separate /64 from its delegated prefix(es) to 
 >new   and

             SHOULD log a system management error.

Is the first SHOULD in WPD-3 strong enough, or would MUST be better?
i.e.
 >new   MUST assign a separate /64 from its delegated prefix(es) to each 
of as many of its LAN interfaces as possible,
 >new   and

Hemant Singh (shemant) wrote:
> *Sent:* Saturday, March 17, 2012 3:25 PM
> *Cc:* STARK, BARBARA H; [email-masked] WG; Wuyts Carl
> *Subject:* Re: [v6ops] RFC6204bis-07
>
> carefully, I've also tried to draft alternative text myself for 
> further consideration:
>
> IPv6 CE router
> * *SHOULD assign a separate /64 from its delegated prefix(es) to each 
> of as many of its LAN interfaces as possible,
>
> it" comment), that can be tested for compliance (Carl's comment that 
> no behavior was defined that could be compliance tested and thus this 
> was a redundant requirement), still deprecates single /64 (my concern) 
> without over-stepping what is already generally agreed in BCP157 
> (Barbara's "A normative reference for the CE router to ensure that the 
> access network always provides something bigger than a /64  is 
> meaningless and useless."), prevents SLAAC being broken by assignment 
> of longer than /64 prefixes on the LAN or some other prefix sharing 
> hack (a lot of people's concern), and does raise an error (your 
> suggestion to do something to alert a human to the undesirable 
> situation) .
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 17 Mar 2012 19:50:25 -0500

Ray,

From: Ray Hunter [mailto:[email-masked]] 
Sent: Saturday, March 17, 2012 6:29 PM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; [email-masked]; Wuyts Carl
Subject: Re: [v6ops] RFC6204bis-07

>>new   provided in BCP 157 (RFC6177) [RFC6177]. 

If we can leave the two bullets as is except adding the above text to
WPD-2 that works best.  We'd like least text to be disturbed unless
there imperative need to edit/add more text.

Thanks and regards,

Hemant

---

From: Ray Hunter <[email-masked]>
Date: Sun, 18 Mar 2012 09:53:47 +0100

I've checked back, and 6204bis-07 does not seem to be any worse than 
6204 on this issue. My main concern, that end users cannot buy a 
replacement 6204bis compliant router and know "it will just work, all 
other things being equal" would not appear to be fixed with just the 
reference to RFC6177, because it seems PD prefix "too short" could still 
result in undefined/unexpected behavior on the LAN interfaces. Speaking 
purely as a consumer, I wouldn't have a lot of faith in such a standard. 
I haven't got a lot more to add to the discussion, except wait and see 
what others opine. We'll definitely hit this topic again in Homenet, and 
maybe that's where it will be solved.

Best regards and thanks.
RayH

Hemant Singh (shemant) wrote:
> *Sent:* Saturday, March 17, 2012 6:29 PM
> *Cc:* STARK, BARBARA H; [email-masked]; Wuyts Carl

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 18 Mar 2012 09:27:28 -0500

Ray,

Ok, I understand the extra important clarification  New text in each
bullet is highlighted in bold. 

        be configurable to ask for more.  Best Current Practice for 

        IPv6 Address Assignment to End Sites is provided in BCP 157 

        (RFC6177) [RFC6177]. 

        delegated prefix is too small to address all of its interfaces, 

        the IPv6 CE router assigns a /64 to each interface until a /64 

        is not available to assign to another interface.  Then the IPv6

        CE router SHOULD log a system management error.

Thanks and regards,

Hemant

---

From: Ole Trøan <[email-masked]>
Date: Sun, 18 Mar 2012 21:06:03 -0700

Hemant,

> Ok, I understand the extra important clarification  New text in each bullet is highlighted in bold.
>  

I'd rather see the added text in the descriptive section instead of as a requirement.
this isn't a requirement for the CE router.

cheers,
Ole

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 19 Mar 2012 08:47:22 +0100

I'm ok with the new things added in bold, still find it a bit odd that the CPE "MUST" ask for a prefix large enough, as large enough is first of all hard to define + you should, in next req, log a system error if you run out of /64's on handing them out, so in fact meaning that you asked a "too small" prefix.  Moreover, "one should be able to configure a different hint", but the hint is '"just" a hint + one MAY do this, not mandatory, hence this does not deliver any added value.  Please note that lots of people will not be able to configure anything in this area, for the simple reason that they should not even know how it works.  The avg home user is interested in ... connectivity, not in size of prefixes, not in IPv6 vs IPv4, etc.

Anyway, to conclude:
For the below
WPD-3 for sure is ok.  You hand out /64s and possibly log a message when you "run out".
WPD-2 is ok wrt hinting the prefix size, ok wrt adding a ref to RFC6177 (to highlight the importance of prefix sizes), but the configurable part should be left out, as it doesn't bring any real added value (apart from extra config possibility to be added to the CPE).

Regs
Carl

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: zondag 18 maart 2012 15:27
To: Ray Hunter
Cc: STARK, BARBARA H; [email-masked]; Wuyts Carl
Subject: RE: [v6ops] RFC6204bis-07

Ray,

Thanks and regards,

Hemant

---

From: Tim Chown <[email-masked]>
Date: Tue, 20 Mar 2012 22:07:34 +0000

On 19 Mar 2012, at 07:47, Wuyts Carl wrote:

> I’m ok with the new things added in bold, still find it a bit odd that the CPE “MUST” ask for a prefix large enough, as large enough is first of all hard to define + you should, in next req, log a system error if you run out of /64’s on handing them out, so in fact meaning that you asked a “too small” prefix.  Moreover, “one should be able to configure a different hint”, but the hint is ‘”just” a hint + one MAY do this, not mandatory, hence this does not deliver any added value.  Please note that lots of people will not be able to configure anything in this area, for the simple reason that they should not even know how it works.  The avg home user is interested in … connectivity, not in size of prefixes, not in IPv6 vs IPv4, etc.

Indeed, the current homenet architecture draft says the homenet must be self-organising as far as possible, to not expose details to users.  We say it should support arbitrary topologies, which means there may be internal routers.  I think if 6204bis is talking about internal interface behaviour, it should if possible be in sync with what's agreed in homenet.   Though I appreciate Hemant's desire to put the 6204bis text to bed.

> Anyway, to conclude:
> For the below
> WPD-3 for sure is ok.  You hand out /64s and possibly log a message when you “run out”.

So if you look at draft-ietf-homenet-arch-02, then section 3.4.7 includes requirement PD6 that talks about prefix pool exhaustion (though it can't say much; if you run out, you're hosed in some way, unless you can ask for and get a bigger prefix).

> WPD-2 is ok wrt hinting the prefix size, ok wrt adding a ref to RFC6177 (to highlight the importance of prefix sizes), but the configurable part should be left out, as it doesn’t bring any real added value (apart from extra config possibility to be added to the CPE).

So the text on prefix delegation in section 3.4.7 of the homenet draft also applies here, and we also talk about adapting to ISP constraints in 3.4.11.  We note there that ISPs may allocate arbitrary sized prefixes, e.g. /56 or /60, and the homenet should make no assumption about the size of prefix offered.  We cite rfc6177 also.

WPD-2 says "large enough for a /64 per interface", but the homenet may also have internal routers. While some routing principles/requirements have been documented, the routing protocol for homenet is not yet determined; it may or may not be aware of the homenet topology.

Tim

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 21 Mar 2012 09:50:48 -0500

Ole,

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Monday, March 19, 2012 12:06 AM
To: Hemant Singh (shemant)
Cc: Ray Hunter; [email-masked]
Subject: Re: [v6ops] RFC6204bis-07

>this isn't a requirement for the CE router.

Agree.  I will move some text to a descriptive section.

Cheers back,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 21 Mar 2012 10:28:28 -0500

Tim,

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tim Chown
Sent: Tuesday, March 20, 2012 6:08 PM
To: IPv6 Operations
Subject: Re: [v6ops] RFC6204bis-07

>WPD-2 says "large enough for a /64 per interface", but the homenet may
also have internal routers. While some routing >principles/requirements
have been documented, the routing protocol for homenet is >not yet
determined; it may or may not be aware of >the homenet topology.

There is a difference between a /64 assigned to a network interface and
a delegated prefix that may be shorter than that.   The text in
rfc6204bis is designed to cover at least a /64 assigned to a network
interface.  The WPD-2 clause in "large enough" is designed to be vague
enough to cover the sub-delegated case if and only if the CE router
supports prefix sub-delegation.  Rfc6204bis can't do any better for text
in these two bullets because rfc6204bis does not cover the specification
for prefix sub-delegation in the home LAN - that is part of the homenet
work. 

Hemant & Wes

Ray,

        (RFC6177) [RFC6177].

Thanks and regards,

Hemant