Subject: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt

From: [email-masked]
Date: Fri, 18 Dec 2009 02:45:01 -0800 (PST)

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)       : H. Singh, et al.
	Filename        : draft-ietf-v6ops-ipv6-cpe-router-03.txt
	Pages           : 14
	Date            : 2009-12-18

This document specifies requirements for an IPv6 Customer Edge (CE)
router.  Specifically, the current version of this document focuses
on the provisioning of an IPv6 CE router and the provisioning of IPv6
hosts attached to it.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 21, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Fred Baker <[email-masked]>
Date: Fri, 18 Dec 2009 09:09:21 -0800

I will open a WGLC on this after new years; My mind will be elsewhere  
for the coming two weeks, I imagine yours will as well. However, if  
you want to start reading/commenting now...

On Dec 18, 2009, at 2:45 AM, [email-masked] wrote:

> <mime-attachment>_______________________________________________
> 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

http://www.ipinc.net/IPv4.GIF

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Dec 2009 09:28:59 +1030

On Fri, 18 Dec 2009 09:09:21 -0800

> you want to start reading/commenting now...

To get the ball rolling ...

"Section 4.1 WAN side configuration

 WLL-1:  The IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]."

I don't see how that can be a MUST when the WAN interface may not
support Ethernet framing e.g. a 3G/HSPDA or Wimax IPv6 CS WAN interface.
Similarly for the PPPoE requirement (and arguably for the PPP
requirement) - 

"WLL-2:  The IPv6 CE router MUST support IPv6 over PPP [RFC5072] and
           PPPoE [RFC2516].  In a dual-stack environment with IPCP and
           IPV6CP running over one PPP logical channel, the NCPs MUST be
           treated as independent of each other and start and terminate
           independently."

I think it would be better to try to avoid making anything relating to
IPv6-over-foo support MUSTs, keeping the scope to IPv6 CPE
requirements. If IPv6-over-foo functions are in scope for the draft,
then I'd suggest making treating them as separate sections, saying
something like, "If the WAN interface supports Ethernet encapsulation,
then it MUST support IPv6 over Ethernet [RFC2464] and PPP [RFC5072]
and PPPoE [RFC2516].", "If the WAN interface supports ATM encapsulation,
then it MUST support PPPoA [RFCXXXX]" etc.

A future CPE's lack of compliance with this draft just because it
doesn't support Ethernet framing on it's WAN interface would be a shame.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Sat, 19 Dec 2009 08:49:54 +0800

Mark,

> doesn't support Ethernet framing on it's WAN interface would be a shame.

I think these are good suggestions.

Best,
Ole

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Dec 2009 16:12:24 +1030

> you want to start reading/commenting now...

Maybe I'm being a bit overly paranoid about people being precious with
IPv6 address space, however, the last sentence of -

"WPD-1:  The IPv6 CE router MUST support DHCP prefix delegation
           requesting router behavior as specified in [RFC3633] (IA_PD
           option).  The IPv6 CE router MUST ask for a prefix large
           enough to cover all of its LAN interfaces."

could be interpreted to mean that the ISP only needs to provide a
prefix to meet the requested size e.g. for two LAN interfaces a /63.
That would seem to me to be encouraging an "only enough" address space
model, rather than a "more than enough" address space model, which is
what I think IPv6 is aiming at.

There might be some value in stating that it is likely that an ISP will
delegate a prefix that not only meets this minimum requirement but also
allows for a number of additional subnets downstream of the CPE, with
the delegated prefix size likely significantly larger, possibly a /48
or /56. IOW, stating that the delegated prefix will likely be larger
than what is requested (not that it is probably likely, but I could see
a CPE vendor adding in a check to see if the delegated prefix size was
equal to that requested, and if it didn't, not using it).

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Dec 2009 16:36:04 +1030

> you want to start reading/commenting now...

I hope I'm not going to look silly because I've missed it, however, do
these CPE (as they are routers) issue RAs on their WAN interface? I'd
think a statement relating to whether they do or don't, and if they do,
what options MUST/MUST NOT etc. are permitted should be covered in the
WAN interface section.

(as a side note, a possible use for these CPE issuing RAs is to
announce support of optional capabilities - I'm thinking about the idea
of prefix-redirects for more optimal inter-CPE traffic flow, and a
prefix-redirect capability announcement to the upstream provider
routers in the CPE's WAN RAs would allow the provider routers to know
not to send prefix-redirects to CPE that don't support that capability)

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Sat, 19 Dec 2009 13:34:21 -0500

> than what is requested (not that it is probably likely, ...

The service provider will most likely completely ignore what size prefix
the CE router is requesting and will provide a prefix sized according to
service provider policy. But the CE router should go ahead and ask, just
in case the service provider does care.

> ... but I could see

This check would be a very Bad Idea for a CE router. Note that CE
routers, by definition, are intended for use in mass market deployments,
by people who don't understand and don't want to understand routing
protocols. They need to be able to just work, no matter what service
provider network they are connected to. And since service providers are
likely to ignore the prefix size request...

Barbara

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Sat, 19 Dec 2009 13:38:55 -0500

> what options MUST/MUST NOT etc. are permitted should be covered in the

You're right -- that requirement seems to have gone missing. Service
providers are fairly unanimous in not wanting to see RA messages coming
from these routers. So it should be explicitly prohibited.

Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Dec 2009 08:58:05 +1300

> what I think IPv6 is aiming at.

Without disagreeing with anything Barbara Stark said, I'm wondering
why the last sentence of WPD-1 is there at all. I mean, why would
an implementer ever ask for too little address space?

> equal to that requested, and if it didn't, not using it).

So if there is anything to say, it's that the CE MUST ask for at least
one /64 per interface and MUST be configurable to ask for more.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 20 Dec 2009 10:00:44 +1030

On Sat, 19 Dec 2009 13:38:55 -0500

> from these routers. So it should be explicitly prohibited.

I'm curious as to what the SPs specific reasons are? While
generally I would default to saying the CPE shouldn't issue RAs, I can
think of some conceivable uses for them if they did.

Regards,
Mark.

---

From: <[email-masked]>
Date: Sat, 19 Dec 2009 22:16:52 -0500

In regards to the sentence in WPD-1: 
"The IPv6 CE router MUST ask for a prefix large enough to cover all of its LAN interfaces."

I believe this sentence is useful for the following reasons:

-Assure contiguous PD requests in a basic CE Router environment (single-homed, no sub-PD) 
-Minimize prefix injection - syncs prefix injection on the SP access router to the prefix size requested by the CE Router (this may or may not be helpful depending on the allocation method but could useful in certain situations)   

Like Barbara mentioned many service providers may choose to control the response from the delegating router to a certain prefix length but this is not assured and may not be implemented by every SP. For basic single-homed operation in an efficient manner the CE Router would determine the number of valid LAN interfaces and ask for an aggregate prefix that covers that range. One option here that would be valid without this statement would be for a CE Router to ask for a separate IA_PD /64 for each interface in separate messages which would be less than optimal.   

Note this by no means limits the CE Router from requesting unique IA_PDs when multiple prefixes per LAN are required and as stated previously prefix subdelegation is out of scope for this document. 

Thanks,

Jason

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Brian E Carpenter [[email-masked]]
Sent: Saturday, December 19, 2009 2:58 PM
To: Mark Smith
Cc: IPv6 Operations
Subject: Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt

    Brian

---

From: <[email-masked]>
Date: Wed, 23 Dec 2009 11:17:18 +0100

see below 

---- snip -----
....
> doesn't support Ethernet framing on it's WAN interface would 
....
---- snip ----- 

Although I see and understand Marks point I think that it would be very helpful to have these statements/requirements somewhere in the document since these are the missing points why such a document makes sense and provides good input for the CPE vendors.

Perhaps it should be written down in a kind of "IF -THAN" language, like
"If the WAN interface of the CE uses Ethernet framing than the CPE MUST support ..." or
"If the WAN interface of the CE uses PPP/PPPoE than in a dual-stack environment with IPCP and IPV6CP running over one PPP logical channel, the NCPs MUST be treated as independent of each other and ...".

Regards
	Olaf