Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

From: Fred Baker <[email-masked]>
Date: Tue, 3 Jan 2012 15:26:46 -0800

Folks - there is a new draft of 6204bis. Those that have issues with previous drafts are encouraged to comment on this version.

Begin forwarded message:

> From: [email-masked]
> Date: December 22, 2011 1:03:18 PM PST
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-v6ops-6204bis-05.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF.
> 
> 	Title           : Basic Requirements for IPv6 Customer Edge Routers
> 	Author(s)       : Hemant Singh
>                          Wes Beebee
>                          Chris Donley
>                          Barbara Stark
>                          Ole Troan
> 	Filename        : draft-ietf-v6ops-6204bis-05.txt
> 	Pages           : 21
> 	Date            : 2011-12-22
> 
>   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 6rd and RFC
>   6333's DS-Lite. are covered in the document.  The document obsoletes
>   RFC 6204, if approved.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-05.txt
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 6 Jan 2012 10:25:15 +0100

WAA-7:  If the IPv6 CE router does not acquire global IPv6
           address(es) from either SLAAC or DHCPv6, then it MUST create
           global IPv6 address(es) from its delegated prefix(es) and
           configure those on one of its internal virtual network
           interfaces, unless configured to require a global IPv6
           address on the WAN interface

I've commented on this a long time ago, when it was WAA-8 in version 02, but seems like it's still more or less in the same unclear condition.
My remarks:
1. what is considered as virtual interface ?
2. what about behavior with ia_pd=64 ?

I've got various answers to question one on the "virtual" interface, already making clear that the description is/was not clear enough.  Some (including myself) considered this virtual intf as the "loop interface", but in this case, it's not even possible when only getting an ia_pd of length=64 (unless some "tricks" gets introduced (e.g. proxy) as suggested by Lorenzo back then).  Other answers suggested to just put this one on the Lan interface of the CPE, so in same subnet as LAN hosts.  This would be ok in ia_pd=64 use case, ok for sourcing IPv6 packets and so on.

>From the above WAA-7 description, I still cannot retrieve that kind of information.  It still mentions "virtual interface", while this is a possibility only in a situation with an ia_pd value < 64.

WPD-5:  If the IPv6 CE router is configured to initiate DHCPv6 before
           receiving a Router Advertisement, it MUST also request an
           IA_NA option in DHCPv6.

Fully disagree.  
First of all, what if stateless configuration is in place ?  the CPE should ask for ia_na ?  
What is RA comes just after it ?
Why should the CPE being charged with a task like this ?  If CAN be configured like this, but for sure it's no mandatory thing!!  As I've mentioned a couple of times before now, from residential CPE point-of-view, too many tasks are being put on the CPE shoulders.  There's no valid reason to enforce the behavior of WPD-5!!!
A CPE must be capable of configuring all kind of models, so be very flexible to meet the customer requirements, but the WPD-5 is nothing to be enforced at all!!

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: woensdag 4 januari 2012 0:27
To: [email-masked] WG
Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

Begin forwarded message:

> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Jan 2012 11:42:39 +0100

Carl,

> I've got various answers to question one on the "virtual" interface, already making clear that the description is/was not clear enough.  Some (including myself) considered this virtual intf as the…

given that all OSes I know about implement virtual network interfaces, I'm not sure I understand what the confusion is?
could add this to the terminology section from: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-04
      LIF  (Logical Interface) - It is a virtual interface in the IP stack.
      It appears just as any other physical interface, provides similar
      semantics with respect to packet transmit and receive functions to
      the upper layers in the IP stack.  However, it is only logical
      construct and is not a representation of an instance of any
      physical hardware.

if you think that helps.

now, with regards to the corner case of a ia_pd=64 and no address on the WAN interface.
if we assume that we agree that giving IPv6 service on the LAN interface is more important than giving the CPE a stable IPv6 address, then the only option within the realm of 6204 is to only configure the LAN interface, and not a virtual interface.

any suggestions for good text including that corner case?

WAA-7:    If the IPv6 CE router does not acquire global IPv6
          address(es) from either SLAAC or DHCPv6, then if the delegated prefix is large enough to assign to each
          of its interfaces it MUST create global IPv6 address(es) from its delegated prefix(es) and
          configure those on one of its internal virtual network
          interfaces.

slightly awkward that text...
we can of course leave it undefined, or strongly recommend that ISPs delegate enough prefixes to number both LAN and internal interfaces.

>           receiving a Router Advertisement, it MUST also request an

this is where I think bis gets it wrong, the 6204 text is:

   WPD-5:  If the IPv6 CE router initiates DHCPv6 before receiving a
           Router Advertisement, it MUST also request an IA_NA option in
           DHCPv6.

> First of all, what if stateless configuration is in place ?  the CPE should ask for ia_na ?  

both SLAAC and DHCP can exist at the same time and both be used for address assignment.

> What is RA comes just after it ?

so what? if the DHCP server didn't give out IA_NAs then nothing was different.
if the DHCP server was willing to give out addresses, but the M bit was unset, well, you do get inconsistent behaviour,
but I would claim that's a configuration error.

> A CPE must be capable of configuring all kind of models, so be very flexible to meet the customer requirements, but the WPD-5 is nothing to be enforced at all!!

actually this requirement was trying to achieve the exact opposite. to simplify the CPE. avoiding a coupling between RA processing and DHCP.
with the above text the two processes can run independently from each other.

(the above assumes that the DHC working group will figure out a solution to multiple stateless option in a single DHCP session).

cheers,
Ole

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 6 Jan 2012 13:02:55 +0100

Ole,

Thx for the fast reply.
Comments inline.

regs
Carl

if you think that helps.

[Carl] not a bad idea

[Carl} 
Why not split it up, i.e., the current text, with clarification on LIF as suggested by you + extra statement on ia_pd=64, so something like:

WAA-7:  If the IPv6 CE router does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, 
		then if ia_pa length >64
			it MUST create global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network
           		interfaces, unless configured to require a global IPv6 address on the WAN interface
		else if ia_pd length=64 
			it must create global IPv6 address(es) from its delegated prefix(es) and configure those on one of its lan interface, unless configured 			to require a global IPv6 address on the WAN interface

OR

WAA-7:  If the IPv6 CE router does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, 
		then if it MUST create global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network
           	interfaces (if ia_pd length >64) or on its lan interface (if ia_pd length = 64), unless configured to require a global IPv6 address on 			the WAN interface

> First of all, what if stateless configuration is in place ?  the CPE should ask for ia_na ?  

both SLAAC and DHCP can exist at the same time and both be used for address assignment
[Carl] agree, but it's not mandatory to have ia_na, so why enforce CPE of asking it in these circumstances ?

so what? if the DHCP server didn't give out IA_NAs then nothing was different.
if the DHCP server was willing to give out addresses, but the M bit was unset, well, you do get inconsistent behaviour, but I would claim that's a configuration error.
[Carl] hm, bit of mixed feeling here, seems like "hiding" behind configuration mistake ...

[Carl] Indeed, de-coupling RA processing from DHCP is exact what I've suggested before, and glad to see some activity on this. However DHCPv6 client can be configured in many ways.  Enforcing "automatic" ia_na requesting is not a good idea.  If you want the CPE to ask for IA_NA, then configure it as such.  With the current statement, there's still coupling of DHCPv6 and RA, but in a different way than before.  I don't see any reason to keep this requirement at all, it does not bring any added value.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Jan 2012 14:08:05 +0100

Carl,

> [Carl] Indeed, de-coupling RA processing from DHCP is exact what I've suggested before, and glad to see some activity on this. However DHCPv6 client can be configured in many ways.  Enforcing "auto…

if we want to keep RA and DHCP processes independent. meaning that the two state machines can be run in parallel.
for the purpose of DHCP, the M/O bits are basically ignored.

if the network only offers addresses via DHCP, how does the network trigger the CPE to ask for an IA_NA?
6204 solution is to require the device to always ask.

cheers,
Ole

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 6 Jan 2012 14:13:21 +0100

if the network only offers addresses via DHCP, how does the network trigger the CPE to ask for an IA_NA?
6204 solution is to require the device to always ask.
[Carl]Just configuration, nothing more, nothing less.  If you want ia_na, ask ia_na, if you don't, don't ask, no need to enforce this.  What if you enforce ia_na and the server doesn't answer anyway ?  Nothing accomplished.  What if you ask ia_na and the server is configured as such to not hand-out anything if ia_na is requested (full match of requested options, if not match fully: nak)
Keep it simple, it's usually the best.  If customer wants ia_na, configure the device as such, don't expect the CPE to do these things "auto-magically"

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: vrijdag 6 januari 2012 14:08
To: Wuyts Carl
Cc: Fred Baker; [email-masked] WG
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

Carl,

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Jan 2012 14:16:45 +0100

Carl,

> Keep it simple, it's usually the best.  If customer wants ia_na, configure the device as such, don't expect the CPE to do these things "auto-magically"

this isn't up to the customer. it is a choice by the access network. and I don't think the "here is a fax from your ISP, just type in these parameters" scheme is the best we can do. ;-)

cheers,
Ole

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 6 Jan 2012 14:19:19 +0100

Carl,

> [Carl]Just configuration, nothing more, nothing less.  If you want 
> ia_na, ask ia_na, if you don't, don't ask, no need to enforce this.  What if you enforce ia_na and the server doesn't answer anyway ?  Nothing accomplished.  What if you ask ia_na and the server is configured as such to not hand-out anything if ia_na is requested (full match of requested options, if not match fully: nak) Keep it simple, it's usually the best.  If customer wants ia_na, configure the device as such, don't expect the CPE to do these things "auto-magically"

[Carl] True, but there will be no "fax" from the ISP to the customer either to ask to switch something in configuration off either if it wouldn't work.  Anyway, I'm always flexible, so I say make it a SHOULD iso MUST, meaning "you should ask it unless you have a good reason not to do so", no ??

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Jan 2012 15:57:08 +0100

Carl,

> [Carl] True, but there will be no "fax" from the ISP to the customer either to ask to switch something in configuration off either if it wouldn't work.  Anyway, I'm always flexible, so I say make i…

the goal here is to specify a CPE that will work on any access network and without any user configuration.
note that this requirement is within an "if block", you only need to do this if you don't want to wait for the RA with the M/O flags.

cheers,
Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 6 Jan 2012 10:07:17 -0500

> > ia_na, ask ia_na, if you don't, don't ask, no need to enforce this.
> What if you enforce ia_na and the server doesn't answer anyway ?
> Nothing accomplished.  What if you ask ia_na and the server is
> configured as such to not hand-out anything if ia_na is requested
(full
> match of requested options, if not match fully: nak) Keep it simple,
> it's usually the best.  If customer wants ia_na, configure the device
> as such, don't expect the CPE to do these things "auto-magically"
> 
> this isn't up to the customer. it is a choice by the access network.
> and I don't think the "here is a fax from your ISP, just type in these
> parameters" scheme is the best we can do. ;-)
> 
> [Carl] True, but there will be no "fax" from the ISP to the customer
> either to ask to switch something in configuration off either if it
> wouldn't work.  Anyway, I'm always flexible, so I say make it a SHOULD
> iso MUST, meaning "you should ask it unless you have a good reason not
> to do so", no ??

<bhs> The current requirement means that the customer doesn't have to
know anything about the access network (SLAAC or DHCPv6 IA_NA or
unnumbered). When we created 6204, one of the core goals was to identify
requirements that would allow a customer to plug the CE router in and
not have to know what address assignment mechanism the access network
used. Changing WPD-5 from MUST to SHOULD would completely demolish that
goal. If someone doesn't want to design their CE router per 6204, then
there's absolutely nothing that says they have to. It's not a
"standard". But if someone wants to build a router that can come up
without user configuration when connected to an access network that does
either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE
router must do. If someone wants a separate RFC for CE routers intended
for a different environment, then that's fine, too. But 6204 is for the
CE router intended to work in the environment specified in 6204.

As for the virtual interface comment -- my recollection of that was that
CE router designers wanted language that would basically let them put
that "unnumbered model" address wherever made sense for their box: LAN
interface, internal interface, logical interface, whatever. No need to
be specific, and leave it up to them. It just isn't the WAN interface
(because there's an RFC that says that's prohibited). From my
perspective, the CE router is a black box. If the access network
provides IA_PD, but no IA_NA and no SLAAC, then I want that CE router to
pick an address from a /64 of the IA_PD and be able to use that address
for sending/receiving traffic to/from the LAN/WAN (while making the
entire rest of that very same /64 available to the LAN for SLAAC). I
think that the new proposals (in the last few emails on this thread) to
split cases around when to put the address on a LAN interface and when
to put it on an internal interface based on = or > /64 in IA_PD go in
exactly the wrong direction. My experience has been that CE router
vendors are perfectly capable of determining the interface that makes
sense for their box. Realistically, the tests run at UNH-IOL wouldn't
check to see what interface the address is on. Because the specific
interface is not externally verifiable. The tests would check for (a) is
the device able to send/receive traffic to/from all ports (assuming LAN
isn't configured for multiple segments) using an address from the IA_PD,
and (b) does it also advertise the rest of that same /64 for use on the
LAN (SLAAC), and (c) do things just work after all this.</bhs>
Barbara

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 6 Jan 2012 16:07:15 +0100

Ole,

[carl] Well, we've the ability to either listen to the RA or not; if not, you decide (in fact it is the operator deciding in our deployment model) what mode you want to run in, so firmware configuration for that operator will either include or not include the ia_na option, no interference from user needed.  Thing is.  If you don't listen/wait for the RA option, you fall back on configuration, so nothing happens "auto-magically"; it's just configuration.  Our protocols can fully run independent, as they should, no coupling unless specifically configured.  It's not the first time, and probably not the last :-), that I'm fighting for protocol de-coupling.  And in our case, no user configuration is needed, just plug the box in.  Please note that I think it's only in "Utopia" that all devices will work on all networks.  You're depending on the access side, you're depending on the used DHCPv6 server, proxy, relay or whatever in use, hence the device works in 100% of the cases is virtually impossible.

Have a nice weekend
Carl

---

From: Ray Hunter <[email-masked]>
Date: Sat, 07 Jan 2012 13:43:48 +0100

Speaking as an end user of the Internet: and in the spirit of your 
comment on virtual interfaces, why should v6ops make life difficult for 
itself and get involved at all in corner cases where there is a conflict 
between what are essentially network operators' deployment decisions, 
and router vendors' engineering decisions? IMVVVVHO V6ops should not be 
defining technical workarounds for non-technical problems like the size 
of the PD assignment.

Various authorities have bent over backwards to ensure that IPv6 
addresses are globally plentiful and that they are "very much cheaper" 
than IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE 
for an IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range 
per household seems unnecessarily mean and potentially harmful to 
transparent end-to-end connectivity on the Internet, possibly forcing 
end users to deploy complex prefix splitting beyond /64 within their CPE 
router and thus breaking SLAAC, or perhaps even worse, deploying NAT66.

Perhaps the practical solution for 6204bis would be for v6ops to 
recommend that network operators delegate "sufficient addresses" to end 
user sites (as suggested earlier by Ole), and perhaps even going as far 
as recommending a minimum PD assignment of /60 or /56 for customers 
using 6204bis compliant equipment. The choice of /60 or /56 being based 
on the ability to potentially delegate reverse DNS, and to allow end 
users of the Internet to deploy flexible and reasonable local topologies 
e.g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 
CE router may have one or more network-layer LAN interfaces).

Regards,
RayH

STARK, BARBARA H wrote:
>>> if the network only offers addresses via DHCP, how does the network
>>>        
>> trigger the CPE to ask for an IA_NA?
>>      
> to put it on an internal interface based on =r>  /64 in IA_PD go in

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 8 Jan 2012 16:09:46 -0600

Carl,

It would also be good to join the cpe router mailing list if you have so
many comments on the document.   Please email [email-masked] and he will
add you to the mailer.  All your questions have been closed in the
design team mailer without changing any more text in the rfc6204bis
document.  An SP doling out an IA_PD of /64 length does not make sense.
The device is an IPv6 router and it is so common for a router to create
a virtual interface to source packets from. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of STARK, BARBARA H
Sent: Friday, January 06, 2012 10:07 AM
To: Wuyts Carl; Ole Troan
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

(full

---

From: Fred Baker <[email-masked]>
Date: Sun, 8 Jan 2012 22:19:19 -0800

I'll add him to the list. However, frankly, it would b good to be having the discussions in the open as the draft is being finalized. It's a working group document.

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 9 Jan 2012 08:15:41 +0100

Well, seems like my comments are being taken the "wrong" way.

To come back on Barbara's comments:
""

<bhs> The current requirement means that the customer doesn't have to know anything about the access network (SLAAC or DHCPv6 IA_NA or unnumbered).

[Carl] I agree

When we created 6204, one of the core goals was to identify requirements that would allow a customer to plug the CE router in and not have to know what address assignment mechanism the access network used.

[Carl] I agree

Changing WPD-5 from MUST to SHOULD would completely demolish that goal. If someone doesn't want to design their CE router per 6204, then there's absolutely nothing that says they have to. It's not a "standard". But if someone wants to build a router that can come up without user configuration when connected to an access network that does either SLAAC or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do.

[Carl But I do not agree on this one. You want a "user configuration" that either does SLAAC, DHCP_IA_NA or unnumbered.  In your opinion, this must be done from a single configuration (no end-user interference, so from "factory defaults").  So, the CPE must either able to "sense" the configuration or just request all of the possible things ??  Sorry, but not a good idea.  So, how must the CPE "sense" this and request the appropriate configuration ?  Listen to RA ?  Fine, although you would run into problems when, on a certain link (just say e.g. PPP), nothing would be received, what would you do with that ?  No RA received, so ask IA_NA ?  Fine again, but what if the DHCPv6 server does not provide anything ?  Then you'd swap to "unnumbered" ?  What interface are you going to use to put an address from ia_pd onto ?  Play "safe" and put it on Lan interface (just to avoid issues if ia_pd = 64) ?

This maybe sounds ok for you, but in fact it's not.  Suppose the CPE has been configured with all of the above, you might end with both putting an address from ia_pd on top of an interface (no matter lan or virtual), which is ok for me, but what if you end up in a situation, where the DHCPv6 server does not return anything unless you ask for a specific set of DHCPv6 options and if not, no info would be sent ?  In that case, you're CPE ends up with ... no configuration at all, only link local addresses.  What if your access network would support SLAAC, so you get a prefix on the WAN intf trough SLAAC, but at the same time, you're also asking IA_NA, so might get that one too + you put a prefix from ia_pa too ?  It can still work, but not sure this would be the best idea though.

So no matter how much more things you're adding for the CPE, you will never have a 100% coverage.

If someone wants a separate RFC for CE routers intended for a different environment, then that's fine, too. But 6204 is for the CE router intended to work in the environment specified in 6204.
""
And on the one of "virtual intfs":
I can of course only agree that CPE vendors are perfectly capable of deciding for the appropriate intf to put an address from ia_pa on top off, however, if your req in RFC6204 uses "virtual interface" then  I'd say your req can never be met in case of ia_pd length = 64.  If you want to keep using this exact phrasing, then it is wrong.  So, if you know state it does not matter what terminology is being used, then I'm wondering why RFcs keep bothering to use lan, wan virtual, ... ???

On the comments from Ray on usage of /64 ia_pd length:
I can only say it is allowed.  I don't say it is a good idea, I don't say we recommend it, but it's being used in the real world, so we're facing it from day to day (again, it's residential market, and we have to cope with those too, as after all, it is valid to use /64).  And although you might consider this to be a "corner case", which I don't think is really the case, then I would imagine it should still be possible to use the RFC, no ?  If not, a statement must be added to the RFC that this is only to be applied if your CPE is using ia_pd lengths of < 64, which goes in against the basic IPv6 RFCs I'd say.

Regs
Carl

From: Ray Hunter [mailto:[email-masked]]
Sent: zaterdag 7 januari 2012 13:44
To: STARK, BARBARA H
Cc: Wuyts Carl; Ole Troan; [email-masked]
Subject: Re: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

Speaking as an end user of the Internet: and in the spirit of your comment on virtual interfaces, why should v6ops make life difficult for itself and get involved at all in corner cases where there is a conflict between what are essentially network operators' deployment decisions, and router vendors' engineering decisions? IMVVVVHO V6ops should not be defining technical workarounds for non-technical problems like the size of the PD assignment.

Various authorities have bent over backwards to ensure that IPv6 addresses are globally plentiful and that they are "very much cheaper" than IPv4 addresses in terms of LIR fees. The equivalent billing in RIPE for an IPv4 /32 is an IPv6 /43. IMVHO assigning a single /64 IPv6 range per household seems unnecessarily mean and potentially harmful to transparent end-to-end connectivity on the Internet, possibly forcing end users to deploy complex prefix splitting beyond /64 within their CPE router and thus breaking SLAAC, or perhaps even worse, deploying NAT66.

Perhaps the practical solution for 6204bis would be for v6ops to recommend that network operators delegate "sufficient addresses" to end user sites (as suggested earlier by Ole), and perhaps even going as far as recommending a minimum PD assignment of /60 or /56 for customers using 6204bis compliant equipment. The choice of /60 or /56 being based on the ability to potentially delegate reverse DNS, and to allow end users of the Internet to deploy flexible and reasonable local topologies e.g. a separate DMZ LAN interface on the CPE router (In 6204bis, an IPv6 CE router may have one or more network-layer LAN interfaces).

Regards,
RayH

STARK, BARBARA H wrote:

(full

to do so", no ??

to put it on an internal interface based on =r > /64 in IA_PD go in

Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 9 Jan 2012 09:56:33 -0500

6204bis is a CE router requirements document. Not an operator
requirements document. 

RFC 6177 provides guidance regarding assignment of IPv6 prefixes to end
sites. Since this RFC already exists, and was recently published, I see
no need to try to write it again at this time.

Barbara

From: Ray Hunter [mailto:[email-masked]] 
Sent: Saturday, January 07, 2012 7:44 AM
To: STARK, BARBARA H
Cc: Wuyts Carl; Ole Troan; [email-masked]
Subject: Re: Re: [v6ops] Fwd: I-D Action:
draft-ietf-v6ops-6204bis-05.txt

Regards,
RayH

STARK, BARBARA H wrote: 

		if the network only offers addresses via DHCP, how does
the network

		6204 solution is to require the device to always ask.
		[Carl]Just configuration, nothing more, nothing less.
If you want
		ia_na, ask ia_na, if you don't, don't ask, no need to
enforce this.

	What if you enforce ia_na and the server doesn't answer anyway ?
	Nothing accomplished.  What if you ask ia_na and the server is
	configured as such to not hand-out anything if ia_na is
requested

(full

	match of requested options, if not match fully: nak) Keep it
simple,
	it's usually the best.  If customer wants ia_na, configure the
device
	as such, don't expect the CPE to do these things
"auto-magically"
	 
	this isn't up to the customer. it is a choice by the access
network.
	and I don't think the "here is a fax from your ISP, just type in
these
	parameters" scheme is the best we can do. ;-)
	 
	[Carl] True, but there will be no "fax" from the ISP to the
customer
	either to ask to switch something in configuration off either if
it
	wouldn't work.  Anyway, I'm always flexible, so I say make it a
SHOULD
	iso MUST, meaning "you should ask it unless you have a good
reason not
	to do so", no ??

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 9 Jan 2012 11:38:48 -0500

By actively engaging in the creation of RFC 6204 and 6204bis, the
operator community engaged in this effort has effectively said that:

1. Operators who expect 6204(bis)-compliant CE routers to work with
their IPv6 access networks won't do things in their IPv6 access networks
that will cause these CE routers not to work. Operators who do not
expect these CE routers to work in their access networks may well do
things that cause these CE routers not to work in their access networks.
It is absolutely true that a 6204(bis)-compliant CE router cannot be
expected to work in an environment where it is not expected to work.

2. Operators who expect 6204(bis)-compliant CE routers to establish a
native IPv6 connection with their access networks will send RA. That RA
may or may not have a SLAAC ("A") prefix. This includes operators who do
PPP. See BBF TR-187
http://www.broadband-forum.org/technical/download/TR-187.pdf. [Things
may change in the future, but that change will have to be coordinated.]

3. Operators who expect 6204(bis)-compliant CE routers to establish a
native IPv6 connection with their IPv6 access networks will have a
DHCPv6 server that provides IA_PD and DNS. It may or may not supply
IA_NA or other config info.

The above operator expectations are implicit in RFC 6204(bis).

The requirements tell the CE router that

a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you
aren't expected to be able to establish an IPv6 connection with this
access network.

b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A"
prefix, that's ok. Clearly, the access network doesn't expect you to do
SLAAC if it doesn't send an "A" prefix. If it does send an "A" prefix,
then it does expect you to do SLAAC.

c) It's OK to always ask for IA_NA. But if M=1, then you MUST ask for
IA_NA. If you get an IA_NA offer, take it. If you don't get one, that's
ok. If the access network doesn't offer an IA_NA after you've asked for
one (or if M=0), then clearly it doesn't intend for you to have one.

d) Always ask for IA_PD. If you don't get IA_PD, then you aren't
expected to be able to establish IPv6 connectivity for your LAN. This
access network has no intention of supplying your LAN with IPv6
connectivity. 

e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then
take a single address from a /64, and associate it with an interface
(not the WAN interface) where you can use the address for
sending/receiving traffic to/from the LAN/WAN. IMO, the entire rest of
the /64 should always be available for use in the LAN. The "unnumbered"
model should never lock up an entire prefix. But we don't say that
anywhere. So I guess operators can't expect this to be the case. I
wouldn't be opposed to either stating that the unnumbered model might
lock up a /64 prefix, or requiring that it not lock up a /64 prefix. But
how to not lock up a prefix (if that's required) should be up to the CE
router vendor to implement.

It's important to understand that if an operator wants these CE routers
to work with their access network, then the operator won't do things
that will cause the device not to work. If an operator doesn't want the
CE router to work with their access network, then you shouldn't expect
to be able to create requirements that will allow the device to work.
Operators should expect CE routers to request IA_NA, independent of what
the operator puts in the RA (M bits, "A" flags). I agree that it's not a
good idea for the operator to support both SLAAC and IA_NA. And
operators know this. Contrary to popular belief, we aren't clueless.
While these requirements do not preclude stupidity in access network
design, operators are working hard (and together) to avoid stupid access
network design. And we're working with the CE community to try to make
sure that we express (reasonable) expectations for devices to work with
the access networks we design. Again, you're absolutely correct that the
expectations we've expressed are not intended to ensure that the devices
work on access networks of operators that have not been engaged in
creation of 6204(bis). But I can only assume that such operators have no
interest in such interoperability. Otherwise, they would be here.

Barbara

From: Wuyts Carl [mailto:[email-masked]] 
Sent: Monday, January 09, 2012 2:16 AM
To: Ray Hunter; STARK, BARBARA H
Cc: Ole Troan; [email-masked]
Subject: RE: Re: [v6ops] Fwd: I-D Action:
draft-ietf-v6ops-6204bis-05.txt

""

unnumbered).

[Carl] I agree 

When we created 6204, one of the core goals was to identify requirements
that would allow a customer to plug the CE router in and not have to
know what address assignment mechanism the access network used.

[Carl] I agree

Changing WPD-5 from MUST to SHOULD would completely demolish that goal.
If someone doesn't want to design their CE router per 6204, then there's
absolutely nothing that says they have to. It's not a "standard". But if
someone wants to build a router that can come up without user
configuration when connected to an access network that does either SLAAC
or DHCPv6 IA_NA or unnumbered, then this is what the CE router must do.

[Carl But I do not agree on this one. You want a "user configuration"
that either does SLAAC, DHCP_IA_NA or unnumbered.  In your opinion, this
must be done from a single configuration (no end-user interference, so
from "factory defaults").  So, the CPE must either able to "sense" the
configuration or just request all of the possible things ??  Sorry, but
not a good idea.  So, how must the CPE "sense" this and request the
appropriate configuration ?  Listen to RA ?  Fine, although you would
run into problems when, on a certain link (just say e.g. PPP), nothing
would be received, what would you do with that ?  No RA received, so ask
IA_NA ?  Fine again, but what if the DHCPv6 server does not provide
anything ?  Then you'd swap to "unnumbered" ?  What interface are you
going to use to put an address from ia_pd onto ?  Play "safe" and put it
on Lan interface (just to avoid issues if ia_pd = 64) ?

This maybe sounds ok for you, but in fact it's not.  Suppose the CPE has
been configured with all of the above, you might end with both putting
an address from ia_pd on top of an interface (no matter lan or virtual),
which is ok for me, but what if you end up in a situation, where the
DHCPv6 server does not return anything unless you ask for a specific set
of DHCPv6 options and if not, no info would be sent ?  In that case,
you're CPE ends up with ... no configuration at all, only link local
addresses.  What if your access network would support SLAAC, so you get
a prefix on the WAN intf trough SLAAC, but at the same time, you're also
asking IA_NA, so might get that one too + you put a prefix from ia_pa
too ?  It can still work, but not sure this would be the best idea
though.

So no matter how much more things you're adding for the CPE, you will
never have a 100% coverage.

If someone wants a separate RFC for CE routers intended for a different
environment, then that's fine, too. But 6204 is for the CE router
intended to work in the environment specified in 6204.

""

I can of course only agree that CPE vendors are perfectly capable of
deciding for the appropriate intf to put an address from ia_pa on top
off, however, if your req in RFC6204 uses "virtual interface" then  I'd
say your req can never be met in case of ia_pd length = 64.  If you want
to keep using this exact phrasing, then it is wrong.  So, if you know
state it does not matter what terminology is being used, then I'm
wondering why RFcs keep bothering to use lan, wan virtual, ... ???

I can only say it is allowed.  I don't say it is a good idea, I don't
say we recommend it, but it's being used in the real world, so we're
facing it from day to day (again, it's residential market, and we have
to cope with those too, as after all, it is valid to use /64).  And
although you might consider this to be a "corner case", which I don't
think is really the case, then I would imagine it should still be
possible to use the RFC, no ?  If not, a statement must be added to the
RFC that this is only to be applied if your CPE is using ia_pd lengths
of < 64, which goes in against the basic IPv6 RFCs I'd say.

Regs

Carl

 

Regards,
RayH

STARK, BARBARA H wrote: 

(full

---

From: Ray Hunter <[email-masked]>
Date: Mon, 09 Jan 2012 18:36:07 +0100

Thanks.

Maybe not on your network, but apparently there are operators out there 
who are forcing router manufacturers to do the best they can with a 
single delegated /64 per end user site.

So why not then quote RFC6177 as an additional normative reference for 
6204bis?

quote rfc6177 > One particular situation that must be avoided is having 
an end site feel compelled to use IPv6-to-IPv6 Network Address 
Translation or other burdensome address conservation techniques because 
it could not get sufficient address space.

quote rfc6177 >  a site, by definition, implies multiple subnets and 
multiple devices

Both quotes seem to be pertinent advice, so that this particular corner 
case is avoided altogether in 6204bis.

regards
RayH

STARK, BARBARA H wrote:
> RFC 6177 provides guidance regarding assignment of IPv6 prefixes to 
> end sites. Since this RFC already exists, and was recently published, 
> I see no need to try to write it again at this time.
>
> Barbara

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 10 Jan 2012 08:28:09 +0100

Well, my final comment on this.

First of all, FYI: operators are our customers, not present in retail.  So all my findings are based upon real life scenarios, not invented.  If I say there's no RA on certain deployments, then it means that there is no RA.  Should they have sent one ?  Probably they should, but they didn't.  does it work: Yes it does.  Operational deployement does not necessarily always line up with the theory of an RFC, this is just a fact, nothing new for IPv6.

I'm just trying to feed in some info from another angle.  I see most contributors in this area are not in our position.
I see you state that you can always ask IA_NA, in fact, looking at those bis reqs, you MUST always ask IA_NA (unless you want some mechanism in place to check for "X Y and Z" to start asking something, but this is no realistic scenario in residential CPE devices).  Please note that lots of operators expect a cheap CPE device, to be able to survice in the market, so putting in lots of extra intelligence is possible, but unlikely to happen.
Please note we try, as all CPEs should do imho, to be compliant with most relevant RFCs.  RFC6204bis being one of them from my point-of-view.

Regs
Carl

From: STARK, BARBARA H [mailto:[email-masked]]
Sent: maandag 9 januari 2012 17:39
To: Wuyts Carl; Ray Hunter
Cc: Ole Troan; [email-masked]
Subject: RE: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

By actively engaging in the creation of RFC 6204 and 6204bis, the operator community engaged in this effort has effectively said that:
1. Operators who expect 6204(bis)-compliant CE routers to work with their IPv6 access networks won't do things in their IPv6 access networks that will cause these CE routers not to work. Operators who do not expect these CE routers to work in their access networks may well do things that cause these CE routers not to work in their access networks. It is absolutely true that a 6204(bis)-compliant CE router cannot be expected to work in an environment where it is not expected to work.
2. Operators who expect 6204(bis)-compliant CE routers to establish a native IPv6 connection with their access networks will send RA. That RA may or may not have a SLAAC ("A") prefix. This includes operators who do PPP. See BBF TR-187 http://www.broadband-forum.org/technical/download/TR-187.pdf. [Things may change in the future, but that change will have to be coordinated.]
3. Operators who expect 6204(bis)-compliant CE routers to establish a native IPv6 connection with their IPv6 access networks will have a DHCPv6 server that provides IA_PD and DNS. It may or may not supply IA_NA or other config info.

The requirements tell the CE router that
a) If you don't get an RA or a response to DHCPv6 SOLICIT, then you aren't expected to be able to establish an IPv6 connection with this access network.
b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A" prefix, that's ok. Clearly, the access network doesn't expect you to do SLAAC if it doesn't send an "A" prefix. If it does send an "A" prefix, then it does expect you to do SLAAC.
c) It's OK to always ask for IA_NA. But if M=1, then you MUST ask for IA_NA. If you get an IA_NA offer, take it. If you don't get one, that's ok. If the access network doesn't offer an IA_NA after you've asked for one (or if M=0), then clearly it doesn't intend for you to have one.
d) Always ask for IA_PD. If you don't get IA_PD, then you aren't expected to be able to establish IPv6 connectivity for your LAN. This access network has no intention of supplying your LAN with IPv6 connectivity.
e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then take a single address from a /64, and associate it with an interface (not the WAN interface) where you can use the address for sending/receiving traffic to/from the LAN/WAN. IMO, the entire rest of the /64 should always be available for use in the LAN. The "unnumbered" model should never lock up an entire prefix. But we don't say that anywhere. So I guess operators can't expect this to be the case. I wouldn't be opposed to either stating that the unnumbered model might lock up a /64 prefix, or requiring that it not lock up a /64 prefix. But how to not lock up a prefix (if that's required) should be up to the CE router vendor to implement.

It's important to understand that if an operator wants these CE routers to work with their access network, then the operator won't do things that will cause the device not to work. If an operator doesn't want the CE router to work with their access network, then you shouldn't expect to be able to create requirements that will allow the device to work. Operators should expect CE routers to request IA_NA, independent of what the operator puts in the RA (M bits, "A" flags). I agree that it's not a good idea for the operator to support both SLAAC and IA_NA. And operators know this. Contrary to popular belief, we aren't clueless. While these requirements do not preclude stupidity in access network design, operators are working hard (and together) to avoid stupid access network design. And we're working with the CE community to try to make sure that we express (reasonable) expectations for devices to work with the access networks we design. Again, you're absolutely correct that the expectations we've expressed are not intended to ensure that the devices work on access networks of operators that have not been engaged in creation of 6204(bis). But I can only assume that such operators have no interest in such interoperability. Otherwise, they would be here.
Barbara

From: Wuyts Carl [mailto:[email-masked]]
Sent: Monday, January 09, 2012 2:16 AM
To: Ray Hunter; STARK, BARBARA H
Cc: Ole Troan; [email-masked]<mailto:[email-masked]>
Subject: RE: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

[Carl] I agree

[Carl] I agree

Regs
Carl

From: Ray Hunter [mailto:[email-masked]]
Sent: zaterdag 7 januari 2012 13:44
To: STARK, BARBARA H
Cc: Wuyts Carl; Ole Troan; [email-masked]<mailto:[email-masked]>
Subject: Re: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

Regards,
RayH

STARK, BARBARA H wrote:

(full

to do so", no ??

Barbara

---

From: François-Xavier Le Bail <[email-masked]>
Date: Mon, 16 Jan 2012 05:59:33 -0800 (PST)

Hi,
G-1:  An IPv6 CE router is an IPv6 node according to the IPv6 Node Requirements [RFC4294] specification. 
RFC 4294 -> RFC 6434 ?

Cheers,
François-Xavier

----- Original Message -----
> From: Fred Baker <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Cc: 
> Sent: Wednesday, January 4, 2012 12:26 AM
> Folks - there is a new draft of 6204bis. Those that have issues with previous 
> drafts are encouraged to comment on this version.
> 
> Begin forwarded message:
> 
>>  A New Internet-Draft is available from the on-line Internet-Drafts 
> directories. This draft is a work item of the IPv6 Operations Working Group of 
> the IETF.
>>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 17 Jan 2012 12:43:16 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of François-Xavier Le Bail
Sent: Monday, January 16, 2012 9:00 AM
To: [email-masked] WG
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

>G-1:  An IPv6 CE router is an IPv6 node according to the IPv6 Node Requirements [RFC4294] specification. 

Thanks much for this catch.  I made the change for the -06 version.

Hemant

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 30 Jan 2012 11:36:26 +0100

Hi,

let me comment from a mobile operator perspective.

From: [email-masked] [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Monday, January 09, 2012 5:39 PM
To: Wuyts Carl; Ray Hunter
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

The above listed expectations so far comply with 3GPP networks at the scenario setting level.

The above is actually more or less aligned with 3GPP networks, which is fine, except that it does not spell out the exclusion case
(as already pointed out on the list earlier, the exclusion case is not 3GPP specific and could be used in other deployments as well).

That means that the delegated prefix in IA_PD might be just half of the reserved prefix to the subscription, in order for the PGW
to be able to do the aggregation of the PDN connection /64 prefix and the delegated prefix to a single prefix.

So it can work, but for the network to be 'sure' things work right, it has to waste some address space with the above mentioned work-around.

Does the 6204bis design team have a clear view on the OPTION_PD_EXCLUDE as specified in draft-ietf-dhc-pd-exclude?

Cheers,
Ales

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 30 Jan 2012 13:45:09 +0100

Nice overview Ales.
Just want to add that I have nothing against the below statements, I fully support them, however, as you mention below requesting IA_NA should be expected by every operator, but the thing is that it should not be depending on check X, Y and Z prior of doing that.  Just request/don't request, and get / don't get it back, perfectly fine.
WRT to the fact that some operators explicitly don't want to sent RA on PPP links.  We can cope with those too, no worries, however, I was just warning about the fact that this happens in real life, not that is should be done like that or not.  Is it "stupid" ?  I don't know, whoami to judge ?   Same goes for DAD on PPP links: do or don't  ?

Regs
Carl

Hi,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Monday, January 09, 2012 5:39 PM
To: Wuyts Carl; Ray Hunter
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

Cheers,
Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 31 Jan 2012 13:08:19 +0100

Hi,

(sorry for re-reposting, email formatting was wrong last time)

> 1. Operators who expect 6204(bis)-compliant CE routers to work with their IPv6 access networks won't do things in their IPv6 access networks that will cause these CE routers not to work. Operators who do not expect these CE routers to 
> work in their access networks may well do things that cause these CE routers not to work in their access networks. It is absolutely true that a 6204(bis)-compliant CE router cannot be expected to work in an environment where it is not 
> expected to work.
> 2. Operators who expect 6204(bis)-compliant CE routers to establish a native IPv6 connection with their access networks will send RA. That RA may or may not have a SLAAC ("A") prefix. This includes operators who do PPP. See BBF TR-187 > http://www.broadband-forum.org/technical/download/TR-187.pdf. [Things may change in the future, but that change will have to be coordinated.]

> b) If you get an "A" prefix in the RA, do SLAAC. If you don't get an "A" prefix, that's ok. Clearly, the access network doesn't expect you to do SLAAC if it doesn't send an "A" prefix. If it does send an "A" prefix, then it does expect you to do > SLAAC.
> c) It's OK to always ask for IA_NA. But if M=1, then you MUST ask for IA_NA. If you get an IA_NA offer, take it. If you don't get one, that's ok. If the access network doesn't offer an IA_NA after you've asked for one (or if M=0), then clearly > it doesn't intend for you to have one.
> e) If you get IA_PD but no IA_NA and you get RA without "A" prefix, then take a single address from a /64, and associate it with an interface (not the WAN interface) where you can use the address for sending/receiving traffic to/from the 
> LAN/WAN. IMO, the entire rest of the /64 should always be available for use in the LAN. The "unnumbered" model should never lock up an entire prefix. But we don't say that anywhere. So I guess operators can't expect this to be the case. I > wouldn't be opposed to either stating that the unnumbered model might lock up a /64 prefix, or requiring that it not lock up a /64 prefix. But how to not lock up a prefix (if that's required) should be up to the CE router vendor to implement.

> It's important to understand that if an operator wants these CE routers to work with their access network, then the operator won't do things that will cause the device not to work. If an operator doesn't want the CE router to work with their > access network, then you shouldn't expect to be able to create requirements that will allow the device to work. Operators should expect CE routers to request IA_NA, independent of what the operator puts in the RA (M bits, "A" flags). I 
> agree that it's not a good idea for the operator to support both SLAAC and IA_NA. And operators know this. Contrary to popular belief, we aren't clueless. While these requirements do not preclude stupidity in access network design, 
> operators are working hard (and together) to avoid stupid access network design. And we're working with the CE community to try to make sure that we express (reasonable) expectations for devices to work with the access networks we
> design. Again, you're absolutely correct that the expectations we've expressed are not intended to ensure that the devices work on access networks of operators that have not been engaged in creation of 6204(bis). But I can only assume 
> that such operators have no interest in such interoperability. Otherwise, they would be here.
> Barbara

Cheers,
Ales