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

From: [email-masked]
Date: Tue, 22 Nov 2011 11:05:08 -0800

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-03.txt
	Pages           : 22
	Date            : 2011-11-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 and transition technologies coexistence.  Two transition
   technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in
   the document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-03.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-03.txt

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Nov 2011 14:05:47 -0600

Folks who are reviewing 6rd sunsetting, please review section 4.4.3 of
this new version of rfc6204bis, especially bullets 5 and 6 and the last
paragraph of the section.  Others, please use the URL provided below to
see a rfcdiff between the -03 and -02 versions.  The DS-Lite bullet
DLW-4 has changed as per Carl's and Francois-Xavier Le Bail comments on
this bullet.

http://tinyurl.com/7rd7bkb

Thanks to all for their comments thus far.

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, November 22, 2011 2:05 PM
To: [email-masked]
Cc: [email-masked]
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

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-03.txt
	Pages           : 22
	Date            : 2011-11-22

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

---

From: jouni korhonen <[email-masked]>
Date: Tue, 22 Nov 2011 23:27:37 +0200

A question.. should RFC6204bis also apply to deployments where the CE WAN link is some sort of cellular link? If that is the case, then current Section 4.2 language may not fit to CEs that e.g. have a LTE radio as the WAN link. For example, WAA-3 and -4 seem to imply statefull DHCPv6 client for address configuration (IA_NA reference here), which would not possible e.g. for LTE. Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).

- Jouni

---

From: Wes Beebee <[email-masked]>
Date: Tue, 22 Nov 2011 16:41:38 -0500

> A question.. should RFC6204bis also apply to deployments where the CE WAN link
> is some sort of cellular link? If that is the case, then current Section 4.2
> language may not fit to CEs that e.g. have a LTE radio as the WAN link. For
> example, WAA-3 and -4 seem to imply statefull DHCPv6 client for address
> configuration (IA_NA reference here), which would not possible e.g. for LTE.
> Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).

Just out of curiosity, how do you envision cellular networks get their
addresses?  Via SLAAC?  What about the PD used for tethered CPEs?

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Nov 2011 15:46:14 -0600

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 4:28 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>A question.. should RFC6204bis also apply to deployments where the CE
WAN link is some sort of cellular link? 

Certainly if the cellular link standards support RFC 3633 for IA_PD
acquisition.

>If that is the case, then current Section 4.2 language may not fit to
CEs that e.g. have a LTE radio as the WAN link. For example, WAA-3 and
-4 seem to imply >statefull DHCPv6 client for address configuration
(IA_NA reference here), which would not possible e.g. for LTE.

Note any cellular standard that mandates that the LTE acquire an IA_PD,
then the WAN of the LTE (the cellular link) has got to use stateful
DHCPv6 because acquiring the IA_PD is a stateful DHCPv6 operation.

>Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).

Agree.  However, the exclude document is not an RFC yet and thus the CPE
router document can't reference this work as a requirement.  

Good to hear from you.

Thanks much.

Hemant

---

From: jouni korhonen <[email-masked]>
Date: Wed, 23 Nov 2011 00:04:45 +0200

Wes,

> addresses?  Via SLAAC?  What about the PD used for tethered CPEs?

I do not envision anything but the fact today is that only SLAAC is supported for the "WAN link". PD is in pipe for tethering but still the WAN side must do SLAAC for CE's own address. And to make life a bit harder the delegated prefix set and WAN link address must aggregate.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Wed, 23 Nov 2011 00:10:58 +0200

Hi Hemant,

> Certainly if the cellular link standards support RFC 3633 for IA_PD

Ok. Good.

> DHCPv6 because acquiring the IA_PD is a stateful DHCPv6 operation.

That is understood. However, WAA-4 has a MUST for IA_NA, which is out of question (in case of WCDMA and LTE).

> router document can't reference this work as a requirement.

Ok. The I-D has been sent to IESG, so maybe it gets out before RFC6204bis does.

- Jouni

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Nov 2011 16:14:00 -0600

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 5:05 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>I do not envision anything but the fact today is that only SLAAC is
supported for the "WAN link". PD is in pipe for tethering but still >the
WAN side must do SLAAC for CE's own address. And to make life a bit
harder the delegated prefix set and WAN link address must >aggregate.

If one does not use the exclude DHC mechanism, then rfc6204 already
specifies use of an unnumbered WAN (WAN has only an IPv6 link-local
address) and then the WAN initiates DHCPv6 for the IA_PD. Once the WAN
acquires the IA_PD, the WAN can use one /128 from this IA_PD prefix and
then delegate the prefix to the LAN segment which would be the tethered
client on the LTE.  The /128 is used to source packets from the WAN.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Nov 2011 16:16:58 -0600

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 5:11 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>Ok. The I-D has been sent to IESG, so maybe it gets out before
RFC6204bis does.

This is great news!  Certainly then I and Wes can look into a new
dhc-exclude bullet in rfc6204bis to cater to the cellular LTE case.  Or
if you can propose some text, that would be great as well.

Cheers,

Hemant

---

From: Wes Beebee <[email-masked]>
Date: Tue, 22 Nov 2011 17:20:09 -0500

> question (in case of WCDMA and LTE).

The capability MUST be there, however we do not go so far as to say that it
MUST always request (or receive) an IA_NA.  The CE router WAN supports
unnumbered operation in addition to numbered operation, of course.

- Wes

---

From: jouni korhonen <[email-masked]>
Date: Wed, 23 Nov 2011 00:30:49 +0200

Hemant,

> client on the LTE.  The /128 is used to source packets from the WAN.

Hmm.. I need to think some text changes/clarifications here, since assuming anything related to unnumbered WAN does not work either.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Wed, 23 Nov 2011 00:35:50 +0200

Wes,

> unnumbered operation in addition to numbered operation, of course.

I still think WAA-4 needs some clarification here. The issue being: WAN does not support unnumbered operation, it does not support IA_NA either but does support IA_PD. Therefore, a MUST for IA_NA needs somehow be conditioned.

- Jouni

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 22 Nov 2011 19:16:26 -0500

> WAN link is some sort of cellular link? If that is the case, then
> current Section 4.2 language may not fit to CEs that e.g. have a LTE
> radio as the WAN link. For example, WAA-3 and -4 seem to imply
> statefull DHCPv6 client for address configuration (IA_NA reference
> here), which would not possible e.g. for LTE. Also, WPD-1 alone would
> not be enough (cf draft-ietf-dhc-pd-exclude).

IMO, any WAN links that are not supported by the current requirements,
are not supported, and support should not be added.

IMO, there's a whole lot more to supporting LTE connections than just
dhc-pd-exclude. Just based on the little I know, I would guess at least
a year's worth of arguing over functionality, with a need for other new
functionality beyond just dhc-pd-exclude. That is, if you really want to
make consumers happy about a CE router with a 3GPP-defined WAN
connection.

But, again, that's just my opinion. 
Barbara

---

From: jouni korhonen <[email-masked]>
Date: Wed, 23 Nov 2011 08:35:27 +0200

Barbara,

> dhc-pd-exclude. Just based on the little I know, I would guess at least

Yes. This was just scratching the surface and poking for the interest.

There are non-trivial scenarios related, for example, lifetimes of delegated prefixes since the WAN link prefix and delegated prefixes are interlinked. But I guess any CE independent of technology would have some level of issues if WAN link prefix renumbering would cause renumbering of the delegated prefix set.

> functionality beyond just dhc-pd-exclude. That is, if you really want to

So far the PD peculiarities and WAN interface DHCPv6 details are the issues. Other stuff seems to be OK.

> make consumers happy about a CE router with a 3GPP-defined WAN

Current breakdown by form factor indicates that ~36% of LTE devices are routers (according to gsacom). No idea what is the actual deployment percentage.

- Jouni

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 03:54:02 -0600

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Wednesday, November 23, 2011 1:35 AM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>There are non-trivial scenarios related, for example, lifetimes of
delegated prefixes since the WAN link prefix and delegated prefixes >are
interlinked. But I guess any CE independent of technology would have
some level of issues if WAN link prefix renumbering would cause
>renumbering of the delegated prefix set.

The above issues are clearly clarified in RFC 3633.  See this text from
section 12.1.

[Each prefix has valid and preferred lifetimes whose durations are

specified in the IA_PD Prefix option for that prefix.  The requesting

router uses Renew and Rebind messages to request the extension of the

lifetimes of a delegated prefix.]

The same text also applies to the exclude pd option.

>So far the PD peculiarities and WAN interface DHCPv6 details are the
issues. Other stuff seems to be OK.

It would be interesting to know the peculiarities. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 05:00:33 -0600

Humble apologies that I cut-and-paste the wrong paragraph from section
12.1 of RFC 3633.  The correct paragraph is below.

  [If the requesting router assigns a delegated prefix to a link to

   which the router is attached, and begins to send router

   advertisements for the prefix on the link, the requesting router MUST

   set the valid lifetime in those advertisements to be no later than

   the valid lifetime specified in the IA_PD Prefix option.  A

   requesting router MAY use the preferred lifetime specified in the

   IA_PD Prefix option.]

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Wednesday, November 23, 2011 4:54 AM
To: jouni korhonen; STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Wednesday, November 23, 2011 1:35 AM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

 

Hemant

---

From: Wes Beebee <[email-masked]>
Date: Wed, 23 Nov 2011 09:11:50 -0500

> Just based on the little I know, I would guess at least
> a year's worth of arguing over functionality...

I tend to agree with Barbara.  In the early days of what became RFC 6204, we
had some interest from the 3GPP community.  However, we never got the levels
of engagement necessary to make sure that we satisfied all of their
requirements.  It's not clear that satisfying half of the requirements is
actually useful to anyone and may cause unnecessary confusion to those
already engaged.

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 09:40:31 -0600

Ok, we can leave comprehensive support for cellular out of rfc6204bis.

Hemant

-----Original Message-----
From: Wes Beebee (wbeebee) 
Sent: Wednesday, November 23, 2011 9:12 AM
To: STARK, BARBARA H; jouni korhonen; Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

> a year's worth of arguing over functionality...

I tend to agree with Barbara.  In the early days of what became RFC
6204, we
had some interest from the 3GPP community.  However, we never got the
levels
of engagement necessary to make sure that we satisfied all of their
requirements.  It's not clear that satisfying half of the requirements
is
actually useful to anyone and may cause unnecessary confusion to those
already engaged.

- Wes

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Nov 2011 12:32:19 +0900

> Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).

Why do you need dhc-pd-exclude at all?

1. You give the phone a prefix delegation for a prefix (say, a /56).
2. You give the phone a RA that says that one particular /64 of that /56 is
in on the WAN link and is to be used for SLAAC.

The phone already has all the information it needs. Why do you need to tell
it twice that the /64 is special?

---

From: jouni korhonen <[email-masked]>
Date: Thu, 24 Nov 2011 07:37:02 +0200

Wes,

I understand your (both or you) points. But we also need to keep in mind that when RFC6204 came out 3GPP community was adding (or had just added) PD into their specs. There was not much point arguing any cellular CE requirement before that (except maybe something tethering related).

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Thu, 24 Nov 2011 07:46:58 +0200

Directly conflicts.. none really. Small nits like MUST for IA_NA on WAN, because that is not needed/supported. On PD side, there are supposedly no issues that are not already covered by 6204bis if the cellular subscription is given a static prefix (on the WAN side). Otherwise, when the WAN link goes down, your delegated prefixes are also "gone". A reference to pd-exclude would be a nice addition since that is part of 3GPP defined PD.

- Jouni

On Nov 24, 2011, at 7:36 AM, Frank Bulk wrote:

> What about traditional SOHO routers that support an LTE USB dongle as a backup WAN link?
> 
> While rfc6204bis may not have everything the 3GPP need, is there anything that directly conflicts?
> 
> Frank
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
> Sent: Wednesday, November 23, 2011 9:41 AM
> To: Wes Beebee (wbeebee); STARK, BARBARA H; jouni korhonen
> Cc: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Nov 2011 09:17:41 +0100

Jouni,

> I understand your (both or you) points. But we also need to keep in mind that when RFC6204 came out 3GPP community was adding (or had just added) PD into their specs. There was not much point argui…

given the exclude option, what else you do need?

cheers,
Ole

---

From: jouni korhonen <[email-masked]>
Date: Fri, 25 Nov 2011 11:30:11 +0200

Ole,

> given the exclude option, what else you do need?

In addition to exclude, probably relaxing MUST for IA_NA (WAA-4) when the stateful address configuration is not plain supported on WAN link. I want to have a confidence for the case where a CE has e.g. a LTE as a backup for fixed connection, the CE does not try to acquire its WAN interface address using DHCPv6 when it switches to LTE... and then get stuck/confused.

The rest can be handled with a subscriber management in the mobile backend.

- Jouni

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Nov 2011 11:08:37 +0100

Jouni,

> In addition to exclude, probably relaxing MUST for IA_NA (WAA-4) when the stateful address configuration is not plain supported on WAN link. I want to have a confidence for the case where a CE has…

I don't see how this case is any different than any other WAN link where address assignment isn't done with DHCP?
the requirement in WAA-4 only says "MUST be capable of".

what is the confusion?
 - CE asks for IA_NA + IA_PD?
 - or CE asks only for IA_PD because it is hardcoded not to do IA_NA on LTE links
 - or CE follows the M flag and does only IA_PD?

in IPv6 we've tried to stick with the principle that provisioning is done on the network layer and done in the same way regardless of data link. I like us to stick to that. which is also why I'm objecting to the "watering down" changes proposed in 6204bis to accommodate the cable case, where address assignment is always done with DHCP.

cheers,
Ole

---

From: jouni korhonen <[email-masked]>
Date: Fri, 25 Nov 2011 13:15:03 +0200

Ole,

> the requirement in WAA-4 only says "MUST be capable of".

So you are saying "MUST be able to support" does not mandate me to implement something? If that is the case, then fine.

> - CE asks for IA_NA + IA_PD?

This one. What would be the expected CE behavior if the server does not include IA_NA in its response?

Can we assume the CE does the right thing (i.e. just asks for IA_PD) when the cellular is a backup and the primary on fixed does ask for IA_NA+IA_PD? If this is the case based on RFC6204bis recommendation, then fine.

> - or CE follows the M flag and does only IA_PD?

This is how I hope this to work. 

> in IPv6 we've tried to stick with the principle that provisioning is done on the network layer and done in the same way regardless of data link. I like us to stick to that. which is also why I'm ob…

Agree.

- Jouni

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Nov 2011 12:24:04 +0100

Jouni,

> So you are saying "MUST be able to support" does not mandate me to implement something? If that is the case, then fine.

no, I'm saying it doesn't say you MUST request an IA_NA on the interface.
with regards to implementation I presume you have to do IA_NA on e.g. wireless interfaces anyway.

> This one. What would be the expected CE behavior if the server does not include IA_NA in its response?

there is an errata for 3315/33633 describing this issue. I'd like to see an update to 3315, as it is written assuming that there will never be any other stateful options in existence.

cheers,
Ole

---

From: jouni korhonen <[email-masked]>
Date: Fri, 25 Nov 2011 15:14:45 +0200

Ole,

> no, I'm saying it doesn't say you MUST request an IA_NA on the interface.

Ok.

> with regards to implementation I presume you have to do IA_NA on e.g. wireless interfaces anyway.

Assuming the code for fixed side would implement it already, sure. Then it is just up to client not to request IA_NA on certain WAN link types. That's ok.

> there is an errata for 3315/33633 describing this issue. I'd like to see an update to 3315, as it is written assuming that there will never be any other stateful options in existence.

Right, thanks. I did not remember these erratas. These would solve my concern on the above case. What's the impact of those as they are still in "reported" status.

- Jouni

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Nov 2011 15:05:55 +0100

Jouni,

> Right, thanks. I did not remember these erratas. These would solve my concern on the above case. What's the impact of those as they are still in "reported" status.

1) nag the DHC chairs to verify the reports (done)
2) do an update of 3315/3633. I don't know if the DHC chairs have any plans for that? or if it just takes some volunteers to get started...

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Nov 2011 17:43:58 +0000

On Nov 25, 2011, at 9:05 AM, Ole Troan wrote:
2) do an update of 3315/3633. I don't know if the DHC chairs have any plans for that? or if it just takes some volunteers to get started...

There's been talk.   We have some thinking to do first.

---

From: Vízdal Aleš <[email-masked]>
Date: Sat, 26 Nov 2011 23:01:48 +0100

Hi Ole, Jouni,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole
> Troan
> Sent: Friday, November 25, 2011 12:24 PM
> To: jouni korhonen
> Cc: [email-masked]
> >>> In addition to exclude, probably relaxing MUST for IA_NA (WAA-4) when the
> stateful address configuration is not plain supported on WAN link. I want to have a
> confidence for the case where a CE has e.g. a LTE as a backup for fixed connection,
> the CE does not try to acquire its WAN interface address using DHCPv6 when it
> switches to LTE... and then get stuck/confused.
> >>
> > So you are saying "MUST be able to support" does not mandate me to implement
> something? If that is the case, then fine.
> 

I have the same concern as Jouni that the IPv6 CE router (e.g. Mi-Fi device) having a 3GPP access 
based WAN link only would be required to support the IA_NA option on the WAN link to be able to be
compliant to this RFC (I am saying on the WAN link, because this requirement is placed under the WAA 
- WAN Address Allocation section). 

So carefully relaxing it for non-DHCPv6 based address allocation would help to avoid potential 
confusion later.

Would it be possible to use something along the lines of 'The IPv6 CE router MUST be able to support 
the following DHCPv6 options (if DHCPv6 based address allocation supported on the WAN link)' as 
written below?

   WAA-4:  The IPv6 CE router MUST be able to support the following DHCPv6 options 
	(if DHCPv6 based address allocation supported on the WAN link): IA_NA, 
	Reconfigure Accept [RFC3315], and DNS_SERVERS [RFC3646]. The IPv6 CE 
	router SHOULD be able to support the DNS Search List DNSSL option as specfied* 
	in [RFC6106].

* there seems to be a typo - specified

> Ole

Cheers,
Ales

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 27 Nov 2011 11:05:43 -0600

Vizdal,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vízdal Aleš
Sent: Saturday, November 26, 2011 5:02 PM
To: Ole Troan; jouni korhonen
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>- WAN Address Allocation section). 

The rfc6204bis document only supports a cellular client for DHCPv6 PD.  Thus any legacy 3GPP cellular client that does not support DHCPv6 PD acquisition is not supported by rfc6204bis.  Thereafter if the cellular client supports DHCPv6 PD, the device already supports the IA_PD option, so what is the big deal for the client to also support the IA_NA option but the client does not use this option?  Thanks for catching the spelling error for "specified".  It has been fixed.

Hemant

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 28 Nov 2011 11:20:09 +0100

Hemant,

> From: Hemant Singh (shemant) [mailto:[email-masked]]
> Sent: Sunday, November 27, 2011 6:06 PM
> To: Vízdal Aleš; Ole Troan; jouni korhonen
> Cc: [email-masked]
> Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
> 
> Vizdal,
> 
> The rfc6204bis document only supports a cellular client for DHCPv6 PD.  Thus any
> legacy 3GPP cellular client that does not support DHCPv6 PD acquisition is not
> supported by rfc6204bis.  

OK.

> Thereafter if the cellular client supports DHCPv6 PD, the
> device already supports the IA_PD option, so what is the big deal for the client to also
> support the IA_NA option but the client does not use this option?  

What is the issue you currently see with relaxing this one for a non-DHCPv6 based address 
allocation?

Even if supported by the IPv6 CE, the support for it cannot be verified as the 3GPP nodes 
along the path do not support statefull address allocation. 

I would see beneficial to allow 'current' 3GPP compliant CEs to be compliant to this RFC as well.

> Thanks for catching the spelling error for "specified".  It has been fixed.

You're welcome.

Cheers,
Ales

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Nov 2011 11:48:20 +0100

Vizdal,

different access networks may have different policies or the data link type may have various restrictions with regards
to address allocation. if it is unnumbered, SLAAC, DHCP or both SLAAC and DHCP.

e.g. typically Cable networks only use DHCP. DSL networks do either model. 6rd makes up an address based on an IPv4 address and so on.

I don't understand how 3GPP links are any different. does it harm functioning on a 3GPP link if the CE is _capable_ of doing DHCP address assignment?

cheers,
Ole

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 28 Nov 2011 12:30:42 +0100

Ole,

> From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Monday, November 28, 2011 11:48 AM
> To: Vízdal Aleš
> Cc: Hemant Singh (shemant); jouni korhonen; [email-masked]
> e.g. typically Cable networks only use DHCP. DSL networks do either model. 6rd makes
> up an address based on an IPv4 address and so on.
> 
> I don't understand how 3GPP links are any different. does it harm functioning on a 3GPP
> link if the CE is _capable_ of doing DHCP address assignment?

There seems to be a misunderstanding, the point Jouni and myself are trying to make is that 
the IA_NA option is not required by the current 3GPP specs, so is less likely to be supported
by the CEs (e.g. MiFi) and potentially preventing them to be compliant to this RFC which we 
see beneficial (the compliancy).

@Jouni, would you agree?

Cheers,
Ales

> >>> I have the same concern as Jouni that the IPv6 CE router (e.g. Mi-Fi device)
> having a
> >> 3GPP access
> >>> based WAN link only would be required to support the IA_NA option on the WAN
> link
> >> to be able to be

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 28 Nov 2011 14:59:56 -0500

I'll re-iterate what I've said before, as to what I need from 6204:

Above all, this document MUST provide guidance for off-the-shelf routers that have no knowledge, whatsoever, of who or what is providing the WAN interface. I will not support any proposed language that strays from this.

BBF, CableLabs, 3GPP, et al are 100% free to specify whatever they want for devices that they are able to specify. If they want to stray from 6204, they are free to do so. 

With that said, I understand that (a) 6204 is driving "IPv6 Ready" logo for routers (b) other orgs would like for their devices to also be able to receive the logo, and (c) it would be nice if we could avoid providing lots of reasons for other orgs to want to stray.

So what we have agreed in a few instances is to use language that makes it clear when it's ok not to do something that would be required of a router with no clue as to its WAN. For example, in WAA-7, it is proposed to add the phrase "... unless configured to require a global IPv6 address on the WAN interface." A WAN-clueless CE router would not be so configured, unless it has knowledge of what to expect on its WAN. 

If you want to propose language that stipulates when it's ok not to request IA-NA, I'm willing to consider that. But I'm not willing to consider any change that would allow a WAN-clueless CE router to not request IA_NA, and still be compliant with 6204(bis).
Barbara

> Of Vízdal Aleš
> Sent: Monday, November 28, 2011 5:20 AM
> To: Hemant Singh (shemant); Ole Troan; jouni korhonen
> Cc: [email-masked]
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Vízdal
> > Aleš
> > >I have the same concern as Jouni that the IPv6 CE router (e.g. Mi-Fi
> device) having a
> > 3GPP access
> > >based WAN link only would be required to support the IA_NA option on
> the WAN link
> > to be able to be
> > >compliant to this RFC (I am saying on the WAN link, because this
> requirement is
> > placed under the WAA

---

From: Hans Liu <[email-masked]>
Date: Tue, 29 Nov 2011 10:29:21 +0800

Barbara,

> BBF, CableLabs, 3GPP, et al are 100% free to specify whatever they want for devices that they are able to specify. If they want to stray from 6204, they are free to do so.
That will be a headache to us small manufactures.

> With that said, I understand that (a) 6204 is driving "IPv6 Ready" logo for routers (b) other orgs would like for their devices to also be able to receive the logo, and (c) it would be nice if we c…
ow a WAN-clueless CE router to not request IA_NA, and still be
compliant with 6204(bis).

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 22:01:13 -0600

Hans,

-----Original Message-----
From: Hans Liu [mailto:[email-masked]] 
Sent: Monday, November 28, 2011 9:29 PM
To: STARK, BARBARA H
Cc: Vízdal Aleš; Hemant Singh (shemant); Ole Troan; jouni korhonen; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>> BBF, CableLabs, 3GPP, et al are 100% free to specify whatever they want for devices that they are able to specify. If they >>want to stray from 6204, they are free to do so.

>That will be a headache to us small manufactures.

Would your headache be reduced if rfc6204bis added a new section for Conceptual Configuration Variables?  One conceptual configuration variable would be a WAN setting for the WAN to be (a) Unnumbered (with only an IPv6 link-local address) and DHCPv6 acquires only IA_PD, (b) Numbered where the WAN acquires a global IPv6 address from DHCPv6 IA_NA IA_address and a prefix via IA_PD, and perhaps an option (c) where the WAN is assigned a static IPv6 global address.  DSL, Cable, and cellular wireless supporting IA_PD will be covered by the WAN setting described above.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 22:26:26 -0600

Hans,

One more clarification.   At least the cable changes over rfc6204bis are only for what’s called as an eRouter cable modem (CM) which is a CM combined with an IPv6 CE router in one single device.   If a small retail CE router vendor such as yourself builds only a standalone IPv6 CE router, the cable changes do not affect your device.  Barbara can reply for the DSL changes for standalone and combined DSL modem and IPv6 CE router in one device.

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Monday, November 28, 2011 11:01 PM
To: Hans Liu; STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hans,

-----Original Message-----
From: Hans Liu [mailto:[email-masked]] 
Sent: Monday, November 28, 2011 9:29 PM
To: STARK, BARBARA H
Cc: Vízdal Aleš; Hemant Singh (shemant); Ole Troan; jouni korhonen; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hemant

---

From: jouni korhonen <[email-masked]>
Date: Tue, 29 Nov 2011 13:54:37 +0200

> see beneficial (the compliancy).

Yes..ish. My main concerns are on off-the-shelf routers that have no knowledge, whatsoever, of who or what is providing the WAN interface. This can be summarized:

o if CE router sends both IA_NA+IA_PD simultaneously and either receives
  NoAddrsAvail in Advertise/Reply(?) for IA_NA or no IA_NA at all, what
  happens. RFC3315 errata 2471 (and RFC3633 errata 2469) should cover this.
  Maybe s short note along the lines of errata texts in WPD-7 would suffice?

And then a reference to pd-exclude (I guess this was already accepted.. once it is out as an RFC).

Is this reasonable?

- Jouni

---

From: Hans Liu <[email-masked]>
Date: Wed, 30 Nov 2011 00:29:05 +0800

Hemant,

> One more clarification.   At least the cable changes over rfc6204bis are
> only for what’s called as an eRouter cable modem (CM) which is a CM combined
> with an IPv6 CE router in one single device.   If a small retail CE router
> vendor such as yourself builds only a standalone IPv6 CE router, the cable
> changes do not affect your device.  Barbara can reply for the DSL changes
> for standalone and combined DSL modem and IPv6 CE router in one device.

Really?  : -)

>>> BBF, CableLabs, 3GPP, et al are 100% free to specify whatever they want
>>> for devices that they are able to specify. If they >>want to stray from
>>> 6204, they are free to do so.
>
> Would your headache be reduced if rfc6204bis added a new section for
> Conceptual Configuration Variables?  One conceptual configuration variable
> would be a WAN setting for the WAN to be (a) Unnumbered (with only an IPv6
> link-local address) and DHCPv6 acquires only IA_PD, (b) Numbered where the
> WAN acquires a global IPv6 address from DHCPv6 IA_NA IA_address and a prefix
> via IA_PD, and perhaps an option (c) where the WAN is assigned a static IPv6
> global address.  DSL, Cable, and cellular wireless supporting IA_PD will be
> covered by the WAN setting described above.

I think so. At least, it is clear what are covered and what are out of scope.

> Hemant

Hans

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Nov 2011 10:52:59 -0600

Hans,

I will discuss with the CPE design team and get their input on adding the Conceptual Configuration section to rfc6204bis.  

Thanks,

Hemant

-----Original Message-----
From: Hans Liu [mailto:[email-masked]] 
Sent: Tuesday, November 29, 2011 11:29 AM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; [email-masked]; Claire Cheng
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hemant,

Really?  : -)

Hans

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 29 Nov 2011 12:02:15 -0500

The specific orgs create requirements that are used by their constituents when procuring devices that are specifically intended to operate on the constituents’ networks. These are often managed devices. They are not WAN-clueless devices. They exist, the specs exist, and this is just the way things are. I’m not aware of anything anybody can do to change this. My reason for stating this fact was to simply make sure we all understood this fact. It is what it is.

Hemant, I don’t quite understand what you’re proposing, but it makes me uncomfortable. The WAN-clueless device must not require user configuration when connected to a particular WAN, if at all possible. That was a very important design principle. The 6204 requirements were intended to allow the WAN interface to automatically establish connectivity, no matter which WAN it connected to (to the greatest extent possible). I’m ok if some of the 6204bis requirements provide exceptions for devices that are configured certain ways. This acknowledges that it is possible for such pre-configured devices to exist. But explicitly describing and calling out these configuration possibilities in their own section is something I’m not in favor of. The configuration exclusions are there to allow other orgs wiggle-room when writing their own specs. They aren’t something that WAN-clueless devices should need to know anything about.

Barbara

Cc: Vízdal Aleš; Ole Troan; jouni korhonen; [email-masked]

Hans,

-----Original Message-----
From: Hans Liu [mailto:[email-masked]] 
Sent: Monday, November 28, 2011 9:29 PM
To: STARK, BARBARA H
Cc: Vízdal Aleš; Hemant Singh (shemant); Ole Troan; jouni korhonen; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hemant

---

From: Wes Beebee <[email-masked]>
Date: Tue, 29 Nov 2011 13:08:07 -0500

>And then a reference to pd-exclude (I guess this was already accepted.. once it

+1

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Nov 2011 12:29:42 -0600

Barbara,

From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Tuesday, November 29, 2011 12:02 PM
To: Hemant Singh (shemant); Hans Liu
Cc: Vízdal Aleš; Ole Troan; jouni korhonen; [email-masked]
Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>Hemant, I don’t quite understand what you’re proposing, but it makes me uncomfortable. The WAN-clueless device must not require user configuration when connected to a particular WAN, if at all possible. That was a >very important design principle. The 6204 requirements were intended to allow the WAN interface to automatically establish connectivity, no matter which WAN it connected to (to the greatest extent possible). I’m ok if >some of the 6204bis requirements provide exceptions for devices that are configured certain ways. This acknowledges that it is possible for such pre-configured devices to exist. But explicitly describing and calling out these >configuration possibilities in their own section is something I’m not in favor of. The configuration exclusions are there to allow other orgs wiggle-room when writing their own specs. They aren’t something that WAN->clueless devices should need to know anything about.

Specifically, the rfc6204bis document has augmented bullets from rfc6204 with text such as “unless configured to acquire a global address…”.  So the user of a CE is going to configure the CE for one specific WAN IP address acquisition behavior.  Thus  why not sell out the Conceptual Configuration Variables?  Further the unnumbered model is buried in text of rfc6204 and rfc6204bis and increasingly we see new readers of the documents having missed the unnumbered model.   Hence why not  define such variables to map out the total scope of the WAN IP configuration for the CE.   The variables do not prohibit a CE to implement automated WAN IPv6 address acquisition/creation.   If you want and if we define Conceptual Configuration Variables, we can add a line that says the WAN IPv6 address acquisition is automated and some guidelines are provided for automata in section 4.4.3.

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 29 Nov 2011 14:31:42 -0500

> Specifically, the rfc6204bis document has augmented bullets from rfc6204 with text such as “unless configured to acquire a global address…”.  So the user of a CE is going to configure the CE for one specific WAN IP address acquisition behavior.  Thus  why not sell out the Conceptual Configuration Variables?  Further the unnumbered model is buried in text of rfc6204 and rfc6204bis and increasingly we see new readers of the documents having missed the unnumbered model.   Hence why not  define such variables to map out the total scope of the WAN IP configuration for the CE.   The variables do not prohibit a CE to implement automated WAN IPv6 address acquisition/creation.   If you want and if we define Conceptual Configuration Variables, we can add a line that says the WAN IPv6 address acquisition is automated and some guidelines are provided for automata in section 4.4.3. <

<bhs> No. There is no expectation that the user of the CE will configure it for a specific WAN. The expectation is that the CE will have a factory default configuration, because the particular CE is intended for use in a particular environment. These configuration exceptions are not intended for WAN-clueless CE routers. They are intended for WAN-specific CE routers.

The exceptions give the specifiers of WAN-specific CE routers (CableLabs, BBF, 3GPP) the freedom to not implement certain capabilities, because their WAN is known to them. The exceptions need to be ignored by WAN-clueless router implementers. WAN-clueless CE routers have no need for these configuration concepts. I don't want to give the impression that such configurability is needed or encouraged in WAN-clueless CE routers. Of course they are not prohibited from offering such configuration, but by remaining silent on the topic, such configurability is neither encouraged nor prohibited.  </bhs
Barbara

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Nov 2011 14:12:41 -0600

Barbara,

OK - appreciate the input.  I will let Hans and you decide on this one since Hans is leaning towards a Conceptual Configuration Variables section. 

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Nov 2011 09:29:31 +1300

On 2011-11-30 08:31, STARK, BARBARA H wrote:
>> Specifically, the rfc6204bis document has augmented bullets
>> from rfc6204 with text such as “unless configured to
>> acquire a global address…”.  So the user of a CE is going
>> to configure the CE for one specific WAN IP address
>> acquisition behavior.  Thus  why not sell out the
>> Conceptual Configuration Variables?  Further the unnumbered
>> model is buried in text of rfc6204 and rfc6204bis and
>> increasingly we see new readers of the documents having
>> missed the unnumbered model.   Hence why not  define such
>> variables to map out the total scope of the WAN IP
>> configuration for the CE.   The variables do not prohibit a
>> CE to implement automated WAN IPv6 address
>> acquisition/creation.   If you want and if we define
>> Conceptual Configuration Variables, we can add a line that
>> says the WAN IPv6 address acquisition is automated and some
>> guidelines are provided for automata in section 4.4.3. <
> 
> <bhs> No. There is no expectation that the user of the CE
> will configure it for a specific WAN. The expectation is that
> the CE will have a factory default configuration, because the
> particular CE is intended for use in a particular
> environment. These configuration exceptions are not intended
> for WAN-clueless CE routers. They are intended for
> WAN-specific CE routers.

Conceptually, it seems to me that we (the IETF) should model a
WAN-specific CE as a WAN-clueless CE with one or more
WAN-specific modules attached; the two aspects should be
described separately.

That is not to say that vendors will implement WAN-specific
devices in this way, but it seems like the only way to make the
spec future-proof.

   Brian

> 
> The exceptions give the specifiers of WAN-specific CE routers
> (CableLabs, BBF, 3GPP) the freedom to not implement certain
> capabilities, because their WAN is known to them. The
> exceptions need to be ignored by WAN-clueless router
> implementers. WAN-clueless CE routers have no need for these
> configuration concepts. I don't want to give the impression
> that such configurability is needed or encouraged in
> WAN-clueless CE routers. Of course they are not prohibited
> from offering such configuration, but by remaining silent on
> the topic, such configurability is neither encouraged nor
> prohibited.  </bhs Barbara

---

From: Hans Liu <[email-masked]>
Date: Wed, 30 Nov 2011 22:39:42 +0800

Barbara,
> <bhs> No. There is no expectation that the user of the CE will configure
it for a specific WAN. The expectation is that the CE will have a >factory
default configuration, because the particular CE is intended for use in a
particular environment. These configuration exceptions are >not intended
for WAN-clueless CE routers. They are intended for WAN-specific CE routers.
>
> The exceptions give the specifiers of WAN-specific CE routers (CableLabs,
BBF, 3GPP) the freedom to not implement certain capabilities, >because
their WAN is known to them. The exceptions need to be ignored by
WAN-clueless router implementers. WAN-clueless CE routers >have no need for
these configuration concepts. I don't want to give the impression that such
configurability is needed or encouraged in WAN->clueless CE routers. Of
course they are not prohibited from offering such configuration, but by
remaining silent on the topic, such >configurability is neither encouraged
nor prohibited.  </bhs
> Barbara

CE in the retail have a factory default configuration, but it doesn't
exactly mean it is intended for use in a particular environment. Tender
project, yes, but not retail products.  In addition to Cable and Broadband,
lots of CE routers in the market have a USB port and support 3G as well.

Take my own implementation as an example. My previous implementation sends
RS, waits for an RA, and then initiates DHCP Solicitation. It is good with
6204 (I assume it is since it passed UNH-IOL in May).  I was later informed
by a BGN vendor that I should also follow the flow addressed in TR-124i2
since it is a MUST (WAN.IPv6.1), and my implementation has an IOT issue
with their BNG.  It only hands out RA after a DHCPv6 process, so I update
my implementation, and my current implementation does RS and DHCP
Solicitation in parallel. I believe my current implementation is still good
with 6204 (It once again passed UNH-IOL in this Nov.)

It is a retail CE router device (with USB, supporting 3G).  Can I keep my
previous implementation and ignore the IOT since it looks ok under
6204/6204bis?  If there is no logo program, maybe we're cool. However, if
there is a logo program and the program is gonna based on a particular RFC
or document, then I believe it will be great if we can make it clear.  If I
can get the logo with my previous implementation, then it means here is the
logo on the giftbox but it cannot promise the device works for an end
user's environment!?

I'm not an expert here but as a vendor, I just want to highlight the
concerns we faced. Devices vendors may hesitate to move into IPv6 if they
don't have a clear guideline to follow.

Hans

-- 
Instead of following the fashion, we lead it through.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Nov 2011 11:00:04 -0800

> once it is out as an RFC).

Why do we need pd-exclude again? It seems to me that it's just a way of
giving a mobile terminal information that it already has (via the PD and
the O bit in the RA). Am I missing something?

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 30 Nov 2011 20:12:45 +0100

I support the Jouni’s proposal to add a reference to pd-exclude.
Pd-exclude was initially designed for mobile scenario but it is actually applicable to broadband case too in the scenario where you want to represent one customer with a single prefix,  instead of using one  prefix for the link between the delegating router and the requesting router and another prefix for the home network network.

PD-exclude allows to delegate a single prefix to the home network and than use the PD-exclude option to tell the CPE to exclude a portion of the delegated prefix and use it to number the point to point WAN link between the requesting router (CPE) and the delegated router (BNG)

Regards,
Roberta

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lorenzo Colitti [[email-masked]]
Sent: Wednesday, November 30, 2011 8:00 PM
To: jouni korhonen
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Tue, Nov 29, 2011 at 03:54, jouni korhonen <[email-masked]<mailto:[email-masked]>> wrote:
And then a reference to pd-exclude (I guess this was already accepted.. once it is out as an RFC).

Why do we need pd-exclude again? It seems to me that it's just a way of giving a mobile terminal information that it already has (via the PD and the O bit in the RA). Am I missing something?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 04:24:03 +0900

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <
[email-masked]> wrote:

> PD-exclude allows to delegate a single prefix to the home network and than
> use the PD-exclude option to tell the CPE to exclude a portion of the
> delegated prefix and use it to number the point to point WAN link between
> the requesting router (CPE) and the delegated router (BNG)
>

I still don't see why this is needed.

If you're using the /64 to number the link between the BNG and the CE
router, then the CE router already knows that the /64 is assigned to that
link via the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE,
then you can make the link unnumbered and you don't need to exclude
anything.

So...?

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 30 Nov 2011 20:31:29 +0100

> If you're not using the /64 to number the link between the BNG and the CE, then you can make the link unnumbered and you don't need to exclude
> anything.

You could make the link unnumbered, but the WAN link could also be numbered.
If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both unnumbered and numbered  are considered valid scenarios.
PD-exclude is need in order to build the WAN numbered scenario with a single  prefix.

Roberta

________________________________________
From: Lorenzo Colitti [[email-masked]]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <[email-masked]<mailto:[email-masked]>> wrote:
PD-exclude allows to delegate a single prefix to the home network and than use the PD-exclude option to tell the CPE to exclude a portion of the delegated prefix and use it to number the point to point WAN link between the requesting router (CPE) and the delegated router (BNG)

If you're using the /64 to number the link between the BNG and the CE router, then the CE router already knows that the /64 is assigned to that link via the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE, then you can make the link unnumbered and you don't need to exclude anything.

So...?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Nov 2011 11:34:13 -0800

On Wed, Nov 30, 2011 at 11:31, Maglione Roberta <
[email-masked]> wrote:

> > If you're not using the /64 to number the link between the BNG and the
> CE, then you can make the link unnumbered and you don't need to exclude
> > anything.
>
> If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both
> unnumbered and numbered  are considered valid scenarios.

As I stated in the part of my email that you didn't quote: in the numbered
scenario, why can't you use the O bit in the RA to indicate that the prefix
is assigned to the link? Then the CE router will have all the information
that it needs.

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 30 Nov 2011 21:03:37 +0100

Hi Lorenzo,

the Prefix Delegation RFC 3633 states a limitation in section 12.1 that 'a prefix delegated to
a requesting router cannot be used by the delegating router'. This limitation is a problem for
the 3GPP case where they have standardised that the link prefix (/64) and the delegated prefix
shall be aggregatable to a single prefix. So, you can use pd-exclude to signal the prefix part
in use.

Cheers,
Ales

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, November 30, 2011 8:00 PM
To: jouni korhonen
Cc: Vízdal Aleš; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Nov 2011 12:12:07 -0800

On Wed, Nov 30, 2011 at 12:03, Vízdal Aleš <[email-masked]> wrote:

> the Prefix Delegation RFC 3633 states a limitation in section 12.1 that 'a
> prefix delegated to a requesting router cannot be used by the delegating
> router'. This limitation is a problem for the 3GPP case where they have
> standardised that the link prefix (/64) and the delegated prefix shall be
> aggregatable to a single prefix. So, you can use pd-exclude to signal the
> prefix part
>
> in use.
>

Fine, but if the only problem is that text, then why do we need a new
option? Can't we just say somewhere that if the part of the prefix is used
to connect the requesting router to the network, then the network MUST
signal that to the client using some other means such as an RA?

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 30 Nov 2011 21:25:06 +0100

Why using “some other means” when  you can achieve this behavior with just a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lorenzo Colitti [[email-masked]]
Sent: Wednesday, November 30, 2011 9:12 PM
To: Vízdal Aleš
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Wed, Nov 30, 2011 at 12:03, Vízdal Aleš <[email-masked]<mailto:[email-masked]>> wrote:
the Prefix Delegation RFC 3633 states a limitation in section 12.1 that 'a prefix delegated to a requesting router cannot be used by the delegating router'. This limitation is a problem for the 3GPP case where they have standardised that the link prefix (/64) and the delegated prefix shall be aggregatable to a single prefix. So, you can use pd-exclude to signal the prefix part
in use.

Fine, but if the only problem is that text, then why do we need a new option? Can't we just say somewhere that if the part of the prefix is used to connect the requesting router to the network, then the network MUST signal that to the client using some other means such as an RA?

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Nov 2011 21:31:34 +0100

> Why using “some other means” when  you can achieve this behavior with just a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?

indeed. you can't first delegate a prefix to some other administrative entity, and then expect to be able to take that back without explicit signaling. if you did this through an RA or a routing protocol or some other means, you still have to handle potential conflicts. signalling up front is a lot cleaner and it avoids the corner cases.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Dec 2011 09:57:58 +1300

On 2011-12-01 09:12, Lorenzo Colitti wrote:
>> prefix part in use.

Better would be for someone who visits 3GPP land to persuade them to remove
that restriction, which is obviously annoying.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Nov 2011 13:12:08 -0800

On Wed, Nov 30, 2011 at 12:25, Maglione Roberta <
[email-masked]> wrote:

> Why using “some other means” when  you can achieve this behavior with just
> a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?
>

Because you need the RA anyway. If the RA is sufficient, then we don't have
to define another option and manufacturers don't have to implement it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Nov 2011 13:17:19 -0800

On Wed, Nov 30, 2011 at 12:31, Ole Troan <[email-masked]> wrote:

> > Why using “some other means” when  you can achieve this behavior with
> just a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?
>
> indeed. you can't first delegate a prefix to some other administrative
> entity, and then expect to be able to take that back without explicit
> signaling. if you did this through an RA or a routing protocol or some
> other means, you still have to handle potential conflicts. signalling up
> front is a lot cleaner and it avoids the corner cases.
>

Signaling exclusion by itself is not sufficient, because you also need to
tell the requesting router where the excluded prefix is.

For example, what is an implementation supposed to do if it gets a PD of
2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the next hop
for 2001:db8:1:2::/64? Discard? It needs to know, at least for the purpose
of sending unreachables.

Since you need to tell the requesting router where the prefix is anyway,
you might as well just tell it where it is and not bother to tell it that
the prefix is excluded.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 Nov 2011 17:22:07 -0600

Hi Roberta,

You don't need to restrict yourself to the use of a single prefix in IPv6.
Usually DR can allocate many prefixes to the RR.

Besides these prefixes are used for some time and then not needed any more.
I don't see any reason to be so frugal.

Regards,

Behcet

On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta <
[email-masked]> wrote:

> [email-masked]<mailto:[email-masked]>>
> wrote:
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
>

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 1 Dec 2011 00:26:41 +0100

Behcet,
   the reason why you may need to have a single prefix instead of two per customer is in order to have just a single route to install on the BNG instead of two.

Regards
Roberta
________________________________________
From: Behcet Sarikaya [[email-masked]]
Sent: Thursday, December 01, 2011 12:22 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hi Roberta,

You don't need to restrict yourself to the use of a single prefix in IPv6. Usually DR can allocate many prefixes to the RR.

Besides these prefixes are used for some time and then not needed any more. I don't see any reason to be so frugal.

Regards,

Behcet

Roberta

________________________________________
From: Lorenzo Colitti [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
PD-exclude allows to delegate a single prefix to the home network and than use the PD-exclude option to tell the CPE to exclude a portion of the delegated prefix and use it to number the point to point WAN link between the requesting router (CPE) and the delegated router (BNG)

So...?

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 30 Nov 2011 18:17:49 -0600

Roberta,

I don't see that a problem either because usually you can install an
aggregate route.

Regards,

Behcet

On Wed, Nov 30, 2011 at 5:26 PM, Maglione Roberta <
[email-masked]> wrote:

> Behcet,
>   the reason why you may need to have a single prefix instead of two per
> customer is in order to have just a single route to install on the BNG
> instead of two.
>
> Regards
> Roberta
> Besides these prefixes are used for some time and then not needed any
> more. I don't see any reason to be so frugal.
>
> Regards,
>
> Behcet
>
> [email-masked]<mailto:[email-masked]
> ><mailto:[email-masked]<mailto:
> [email-masked]>>> wrote:

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 1 Dec 2011 02:16:25 +0100

Yes you can install the aggregate route but you would need either another dhc option that tells the BNG what aggregate route needs to be installed per each customer or you have to do by manual configuration.
In my opinion using PD-exclude is operational much simpler

Roberta
Sent: Thursday, December 01, 2011 1:17 AM

Roberta,

I don't see that a problem either because usually you can install an aggregate route.

Regards,

Behcet

On Wed, Nov 30, 2011 at 5:26 PM, Maglione Roberta <[email-masked]<mailto:[email-masked]>> wrote:
Behcet,
  the reason why you may need to have a single prefix instead of two per customer is in order to have just a single route to install on the BNG instead of two.

Regards
Roberta
________________________________________
From: Behcet Sarikaya [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 01, 2011 12:22 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hi Roberta,

Regards,

Behcet

Roberta

________________________________________
From: Lorenzo Colitti [[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
PD-exclude allows to delegate a single prefix to the home network and than use the PD-exclude option to tell the CPE to exclude a portion of the delegated prefix and use it to number the point to point WAN link between the requesting router (CPE) and the delegated router (BNG)

So...?

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 30 Nov 2011 23:58:27 -0600

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lorenzo Colitti
Sent: Wednesday, November 30, 2011 4:17 PM
To: Ole Troan
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>For example, what is an implementation supposed to do if it gets a PD
of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the
next hop for 2001:db8:1:2::/64? 

If I read the exclude document
(http://tools.ietf.org/html/draft-ietf-dhc-pd-exclude-03), I see that
the /64 above is used on the RR for the link between the RR and the DR.
Since the DR is the first-hop router for the RR (section 3 of the
exclude document says so), the next-hop for the global /64 above is the
IPv6 link-local address of the DR.  See also this text from section 6.1
of the exclude document.

[The requesting router must create sink routes for the delegated

prefixes minus the excluded prefixes.  This may be done by creating

sink routes for delegated prefixes and more specific routes for the

excluded prefixes.]

I could use a /128 from the excluded /64 on any virtual interface to
source ICMPv6 errors.

Hemant