Subject: Re: Posted a new copy of CPE Rtr draft

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 18:07:05 +0200

On 6 mrt 2009, at 23:27, Hemant Singh (shemant) wrote:

> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-04.txt

now v6ops-ipv6-cpe-router-00, right?

Not having read the subsequent discussion yet, here is my feedback:

Most important issue:

"The CPE Router may also support prefix sub-delegation."

We should make this a MUST. I don't want to end up in the situation  
where I get a crappy DSL IPv6 CPE from my ISP and I can't use my own  
CPE because there is no subdelegation.

If that's too hard, then we must mandate the ability for ISP-provided  
CPEs to run in bridge mode. (But then that CPE would probably still  
need a global address for management.) Preferably the ISP-provided CPE  
would go in bridge mode automatically when a more capable CPE is  
present. I guess this could happen if the ISP-CPE receives a PD request.

In general, information is often repeated.

"A CPE Router is an IPv6 Node"

I would think it's a router... Or do you guys mean that in addition to  
being a router, it must also fulfill the node requirements? If so, may  
want to say so explicitly here.

"The WAN interface is preferred to be Ethernet encapsulated but it may  
support other encapsulations such as PPP."

What about ATM? (I used native IPv6 over ADSL = ATM with a Cisco  
826/827 for years.)

"If no LAN interface is present"

Then what is the function of the CPE?

    Before the CPE Router is initialized, the device must have IPv6
    enabled.  The CPE Router SHOULD support the ability to disable its
    IPv6 stack.  The CPE Router also has the ability to block or forward
    IPv6 traffic to and from the router's LAN interface(s).  [RFC2669]
    includes a MIB definition to block the IPv4 or IPv6 Ethertype in the
    upstream or downstream interface(s) of a device such as the CPE
    Router.  Some portion of this MIB may need to be modified for use
    with the CPE Router.

This kind of detail has the potential to obscure the forrest with  
largely unnecessary trees. On the other hand it's also not so detailed  
that it fully specifies what an implementation is supposed to do. But  
different vendors are likely to have different opinions on that,  
anyway. And if v6 can be disabled, why not v4?

"The CPE Router MUST support at least one of two WAN interface models,"

It takes very long until the other shoe drops, would be better to just  
say "numbered and unnumbered" and then start a new paragraph for the  
discussion of the numbered model.

    In the Numbered model, the WAN interface acquires a global unicast
    address (GUA) using a combination of SLAAC and stateful DHCPv6 for
    IA_PD (no IA_NA) or uses only stateful DHCPv6 for GUA (IA_NA)

So the CPE is required to support address assignment for its WAN  
interface with both DHCPv6 and stateless autoconfig? I don't like that.

"A Loopback interface"

I would say "assigning a stable global unicast address to a loopback  
interface" so as to not confuse people who live in a host-based world  
where loopback interfaces have ::1 as their address.

"The IA_PD is sub-delegated to the LAN interface(s)"

I would say "/64 subprefixes of the IA_PD provided prefix are assigned  
to a LAN interface or multiple LAN interfaces. If the IA_PD only  
provides a /64 (which is NOT recommended) this prefix is assigned to  
one LAN interface."

"Either the Loopback or the LAN interface can be used to source WAN- 
facing traffic."

Like what? (I guess NTP or something like that...)

"if the O bit is set in the RA, the WAN interface acquires other  
configuration information."

What if the O bit is not set? Doesn't the CPE always initiate stateful  
DHCPv6 in order to obtain a prefix?

"Other IPv6 configuration information is obtained using stateless  
DHCPv6."

I don't think it makes sense to perform both stateful and stateless  
DHCPv6.

"The Unnumbered model is incompatible with the strong host model  
[RFC1122] on the CPE router"

Which is irrelevant, the CPE is a ROUTER, and there are no "strong"  
routers, only "strong" hosts.

"where a device that uses the strong host model can operate as a CPE  
Router."

Such devices must not be allowed.

"The CPE Router may include a stateful DHCPv6 server to assign  
addresses to home devices connected via the LAN interface(s) of the  
CPE Router."

That seems rather pointless. And because it's only a MAY there's no  
need to specifically point this out in the text.

But I guess this means that DHCPv6 requests done by hosts on the LAN  
side are never propagated to the ISP?

"The home devices can also acquire addresses via SLAAC."

That's not very specific. Needs to be: the CPE MUST send router  
advertisements with a prefix option once a prefix is available.

    If the IA_PD changes, the CPE Router must reconfigure
    the LAN interface(s) with new IPv6 addresses derived from the new
    IA_PD and then also renumber the IPv6 ND RA configuration on the LAN
    interface(s).

Need to explain that the old and the new prefixes must overlap for  
some time to allow for graceful renumbering.

    This document recommends the RA sent out by LAN Interface(S) to be
    configured for SLAAC so that the prefix advertised in the RA is
    derived from the IA_PD assigned to the CPE Router by the Service
    Provider;

Requires

    the O-bit is also set so that the CPE Router can pass
    Domain Name Server(s) IPv6 address(es) to home devices.

Only if the CPE implements a stateless DHCPv6 server that  
redistributes the DHCPv6 info the router itself got from the ISP, or  
if the router acts as a DHCPv6 relay.

How are ULAs for configuration supposed to work? Obviously you can't  
print the address for configuration in the manual (it being randomly  
generated and all). So at the very least this has to work through the  
DNS. The problem is: how do you get rid of the ULA addresses on hosts  
once global addresses are available?

The only time ULAs outperform link locals is in the case of cascaded  
CPEs where you want to go from host X to CPE A through CPE B. With  
link locals that wouldn't work.

An alternative for the configuration address would be a well-known  
address, so users can be told to go to 2001:db8::1. This could work  
with link locals on the hosts as long as CPEs aren't cascaded.

    initiates L2TPv2 tunnel from
    the CPE Router to tunnel IPv6 data from the home over an IPv4
    network.  The feature is enabled before any IPv6 host in the home is
    connected to the CPE Router or the WAN interface of the CPE Router  
is
    operational.

What does this mean?

It is important that delays or failure with the softwire stuff doesn't  
delay the initiation of native IPv6.

Also, "softwires" is the IETF wg, please use the name of the protocol.

Why is this under the PPP heading?

5.7.  Stateful DHCPv6 Server (CORE)

    The CPE Router may support a stateful DHCPv6 server to serve clients
    on the CPE Router LAN interface(s)

Core but not a requirement???

    If the CPE router supports
    cascading of routers through automatic prefix sub-delegation, the  
CPE
    router MUST support a DHCPv6 server or DHCPv6 relay agent.

(see above). Having a server or a relay are very different for the  
ISP, not good to leave both options open because now the ISP has to  
support both.

Is it mentioned anywhere that if a CPE supports subdelegation, it must  
also be capable of installing routes towards the router that has a  
subdelegation?

"The CPE Router MAY support RIPng in the home network."

For what purpose? RIP is a terrible routing protocol...

    Each of the WAN and LAN interface(s) of the CPE Router must have its
    own L2 (e.g.  MAC) address.

Why? This may make vendors limit the number of interfaces.

"The CPE Router supports ND protocol"

the ND protocol

    both the WAN interface and LAN interface(s) to advertise itself as a
    router to neighbors in the Service Provider and home networks.

You mean it sends RAs on the WAN side? Why???

    If the CPE Router has only one /64 prefix to be used across multiple
    LAN interfaces and the CPE Router supports any two LAN interfaces
    that cannot bridge data between them because the two interfaces have
    disparate MAC layer, then the CPE Router MUST support ND Proxy
    [RFC4389].

No, This will just be used as a reason for ISPs to give users less  
than a /64. If they do that, simply configure 1 LAN interface, no  
special case handling.

"Legacy 3GPP networks have the following requirements:"

I think it would serve the document better to keep such unusual cases  
out of it.

    For these legacy 3GPP networks, the CPE Router MUST support ND Proxy
    between the WAN and LAN interface(s).  However, if the CPE Router  
has
    multiple prefixes available for use on LAN interfaces(s), then ND
    Proxy is not necessary.

First a MUST and then "not necessary" is far from ideal specification  
writing...

About multicast: what happens on wifi, which can't handle non-minimal  
amounts of multicast traffic? (Also see the multicast discussion on  
the homegate list.)

    If the CPE Router hardware includes a network bridge between the WAN
    interface and the LAN interface(s), then the CPE Router MUST support
    MLDv2 snooping as per [RFC4541].

Can't it just treat multicasts as broadcasts? That's why cheap  
switches do AFAIK. I would rather not have MLD snooping, because if  
implemented incorrectly it breaks the network in severe ways. (Like  
boxes that didn't pass IPv6 multicasts because of IGMP snooping.)

"8.1. Path MTU Discovery Support (MEDIUM)"

Why medium? This is absolutely essential to avoid PMTUD black holes,  
one of the scurges of today's internet in general and the IPv6  
internet in particular. The language here MUST be much sharper.

"Ethernet Jumbo frames (9000+ bytes)"

Jumboframes is anything bigger than 1500 bytes.

    The CPE Router may support RIPng routing protocol [RFC2080] so that
    RIPng operates between the CPE Router and the Service Provider
    network.

Have you talked to ISPs about this? Not only is RIP slow, it's also  
insecure. I don't think they want this headache. And what if the ISP  
redistributes 50000 prefixes from other customers to the CPE?

Besides, "MAY" is useless. If 99 CPE vendors support RIP and 1 doesn't  
then the ISPs still can't use it.

"The firewall may"

Again, "may" language is useless. There must be a list of the  
extension headers that firewalls must support.

"CPE Router MAY initiate ISATAP"

How would that work??

    softwires.  Further, any approach which requires the use of a tunnel
    MUST take into account the reduced MTU.

Would be useful to include an MTU option in RAs that reflects the  
usable maximum packet size on the WAN side.

"An AAAA record is relayed to the server."

This sentence doesn't make any sense.

Please refer to the DNS64 document, a CPE either needs to do it right  
or not do it at all.

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Jul 2009 09:21:27 -0700

> now v6ops-ipv6-cpe-router-00, right?

Yes; the currently active CPE drafts are:

http://tools.ietf.org/html/draft-donley-ipv6-cpe-rtr-use-cases-and-reqs
   "Use Cases and Requirements for an IPv6 CPE Router", Chris Donley,  
Deepak
   Kharbanda, John Jason Brzozowski, Yiu Lee, Jason Weil, Kirk  
Erichsen, Lee
   Howard, Jean-Francois Tremblay, 2-Jul-09,
   <draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00.txt>

http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security
   "Recommended Simple Security Capabilities in Customer Premises  
Equipment for
   Providing Residential IPv6 Internet Service", James Woodyatt, 16- 
Jun-09,
   <draft-ietf-v6ops-cpe-simple-security-06.txt>

http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router
   "IPv6 CPE Router Recommendations", Hemant Singh, Wes Beebee, 25- 
Mar-09,
   <draft-ietf-v6ops-ipv6-cpe-router-00.txt>

---

From: james woodyatt <[email-masked]>
Date: Mon, 20 Jul 2009 10:34:01 -0700

> CPE because there is no subdelegation.

Careful with that axe... if we're going to require prefix sub- 
delegation in best-practice CPE routers, then I contend we absolutely  
need to specify how that's done with zero configuration.  Are we ready  
to do that yet?  I don't believe we are.  Very happy to be proven  
wrong about that.

> If that's too hard, then we must mandate the ability for ISP- 
> provided CPEs to run in bridge mode. (But then that CPE would  
> probably still need a global address for management.) Preferably the  
> ISP-provided CPE would go in bridge mode automatically when a more  
> capable CPE is present.  I guess this could happen if the ISP-CPE  
> receives a PD request.

My understanding is that some providers expect to provision their  
networks in an unnumbered fashion, i.e. they MUST be a router, not a  
bridge, and their integrated hosts obtain global addresses by self- 
assigning from the router's delegated prefix.  Having another router  
come along and dynamically replace the integrated router without  
disturbing the host strikes me as a tricky problem.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Jul 2009 11:20:15 -0700

On Jul 20, 2009, at 10:34 AM, james woodyatt wrote:

>> where I get a crappy DSL IPv6 CPE from my ISP and I can't use my  
>> own CPE because there is no subdelegation.
>
> delegation in best-practice CPE routers, then I contend we  
> absolutely need to specify how that's done with zero configuration.   
> Are we ready to do that yet?  I don't believe we are.  Very happy to  
> be proven wrong about that.

Personally, I am uncomfortable with the topic's treatment in this  
document.

draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00.txt and draft-ietf- 
v6ops-ipv6-cpe-router-00.txt both comment on sub-delegation; the  
latter tries to specify an algorithm for it. In a document of this  
type, to my mind, the question is "what RFC MUST/SHOULD/MAY a CPE  
Router implement", not "what algorithm...". That also reflects the  
discussion at IETF 74, which recommended dividing the CPE Router  
Recommendations document into a "2009 recommendations" that would be a  
working group document and listed RFCs, and a "2010 recommendations"  
that was an individual submission and requested RFCs on various topics  
to use in future recommendations. I would be far happier with  
specifying that

a) a CPE router with one external and multiple internal interfaces  
that is delegated a prefix shorter than /64 from its upstream SHOULD  
assign specific /64s from that to its interfaces by an algorithm  
internal to itself, and

b) It would be Really Nice if the 6man working group designed a multi- 
router sub-delegation algorithm for cases in which a small network  
with multiple routers needs to do so within itself.

To me, anything beyond that is not a document making appropriate  
"recommendations" to vendors regarding their products, or to the likes  
of CableLabs or BBF regarding the products they deploy.

I don't see an RFC or Internet Draft in any working group that tries  
to specify sub-delegation for SOHO/SMB networks. Fred Templin has  
three documents that look at the topic, but to my knowledge they have  
not been picked up by any working group.

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Jul 2009 11:33:34 -0700

On Jul 20, 2009, at 11:20 AM, Fred Baker wrote:

>>> We should make this a MUST. I don't want to end up in the  
>>> situation where I get a crappy DSL IPv6 CPE from my ISP and I  
>>> can't use my own CPE because there is no subdelegation.
>>
>> absolutely need to specify how that's done with zero  
>> configuration.  Are we ready to do that yet?  I don't believe we  
>> are.  Very happy to be proven wrong about that.
>
> Recommendations document into a "2009 recommendations" that would be  
> a working group document and listed RFCs, and a "2010  
> recommendations" that was an individual submission and requested  
> RFCs on various topics to use in future recommendations. I would be  
> far happier with specifying that

reword...

> assign specific /64s from that to its non-upstream interfaces by an  
> algorithm internal to itself, and

> b) It would be Really Nice if the 6man working group designed a  
> multi-router sub-delegation algorithm for cases in which a small  
> network with multiple routers needs to do so within itself.

By the way, there are many words of caution that apply to auto-sub- 
delegation of prefixes. In general, one wants them to aggregate in a  
nice way without all the issues of renumbering. That means in part  
that there must be some way to recognize when it is inappropriate to  
use the algorithm, such as saying that it is appropriate to networks  
using PA prefixes and in which internal aggregation is not in use. If  
my upstream gives me a /60, there isn't a lot to discuss. If the  
upstream gives a /56 or a /48 and the site in question has multiple  
campuses, auto-sub-delegation is probably pretty difficult to get right.

> "recommendations" to vendors regarding their products, or to the  
> likes of CableLabs or BBF regarding the products they deploy.
>
> three documents that look at the topic, but to my knowledge they  
> have not been picked up by any working group.
>

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 20 Jul 2009 15:13:38 -0400

> By the way, there are many words of caution that apply to auto-sub-
delegation of prefixes. In general, one
> wants them to aggregate in a nice way without all the issues of
renumbering. That means in part that there must
> be some way to recognize when it is inappropriate to use the
algorithm, such as saying that it is appropriate
> to networks using PA prefixes and in which internal aggregation is not
in use. If my upstream gives me a /60,
> there isn't a lot to discuss. If the upstream gives a /56 or a /48 and
the site in question has multiple
> campuses, auto-sub-delegation is probably pretty difficult to get
right. 

Perhaps what we need here is a default algorithm for auto-sub-delegation
that produces reasonable results in common cases with a manual override
so that if you don't like the results, you can always do it yourself.

- Wes

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 20 Jul 2009 15:13:29 -0400

Fred,
Thanks for this response. I agree with it, completely.
Barbara

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Fred Baker
> Sent: Monday, July 20, 2009 2:34 PM
> To: james woodyatt
> Cc: IPv6 Operations
> Subject: Re: Posted a new copy of CPE Rtr draft
> 
> 

*****

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. GA625

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 22:02:10 +0200

> absolutely need to specify how that's done with zero configuration.

That would certainly be best, but it would be acceptable if you'd have  
to go into the "bad" CPE to make it work correctly in the cascading  
case, IMO.

Unfortunately, I don't think it's possible to manually configure an  
alternative for subdelegation, assuming the (sub)delegation isn't a  
fixed prefix.

>> probably still need a global address for management.) Preferably  
>> the ISP-provided CPE would go in bridge mode automatically when a  
>> more capable CPE is present.  I guess this could happen if the ISP- 
>> CPE receives a PD request.

> disturbing the host strikes me as a tricky problem.

I don't think that's necessary. We could make it such that a CPE  
detects whether other CPEs or non-CPE devices are connected to its LAN  
ports. Then, if only one LAN port is active and that LAN port connects  
to a device identifying as a CPE, the first CPE disables its WLAN  
interfaces, if any, and transparently bridges between its WAN and LAN  
ports. The only question in this scenario is how management of the  
original CPE would happen in the unnumbered scenario. But if that's a  
problem people can always use the numbered scenario...

Iljitsch

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Jul 2009 13:13:23 -0700

As I said, there is a very reasonable algorithm in the most common  
case, which is that the home router is the only router present. To go  
beyond that, I think your document should be referring to the  
implementation of another RFC, and to my knowledge that hasn't been  
written. That was the consensus of the meeting at IETF 74, you will  
recall.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 20 Jul 2009 16:19:32 -0400

> Unfortunately, I don't think it's possible to manually configure an
alternative for subdelegation, 
> assuming the (sub)delegation isn't a fixed prefix.

If you knew how many bits were in the prefix, you could say:
SP prefix : my bits : identifier

Where my bits came from a table of bits and output interfaces.  An
automatic configuration algorithm would simply assign the "my bits" in
the table (perhaps sequentially or randomly).  To manually config, all
you need to do is edit the table of bits.

As long as the SP prefix length didn't change, the table of bits could
remain fixed through a SP renumbering.

To make this practical, you'd need to assume that the table wasn't that
large.  This would work well for a home, but may not be appropriate in
an enterprise scenario.

> I don't think that's necessary. We could make it such that a CPE
detects whether other CPEs or non-CPE devices
> are connected to its LAN ports. Then, if only one LAN port is active
and that LAN port connects to a device
> identifying as a CPE, the first CPE disables its WLAN interfaces, if
any, and transparently bridges between its
> WAN and LAN ports. The only question in this scenario is how
management of the original CPE would happen in the
> unnumbered scenario. But if that's a problem people can always use the
numbered scenario...

Imagine a scenario where the SP manages a router embedded in a cable
modem, and the home user has a router behind that.  Both may want to
administer their own routers at the trust boundary.  Imagine the
surprise from the service provider if they find that their router
suddenly became a bridge!  The user would be surprised if their box
suddenly became a bridge automatically too.

It seems to me that being a bridge or a router is a fundamental change
in the network topology and should not be done "automatically".

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 20 Jul 2009 16:25:07 -0400

Yeah - a very detailed discussion needs to be had here - and a document
to be written.  Perhaps we can have this discussion on this mailer.
However, it is too much detail for the CPE router document.

- Wes 

-----Original Message-----
From: Fred Baker (fred) 
Sent: Monday, July 20, 2009 4:13 PM
To: Wes Beebee (wbeebee)
Cc: james woodyatt; IPv6 Operations
Subject: Re: Posted a new copy of CPE Rtr draft

As I said, there is a very reasonable algorithm in the most common case,
which is that the home router is the only router present. To go beyond
that, I think your document should be referring to the implementation of
another RFC, and to my knowledge that hasn't been written. That was the
consensus of the meeting at IETF 74, you will recall.

On Jul 20, 2009, at 12:13 PM, Wes Beebee (wbeebee) wrote:

> Perhaps what we need here is a default algorithm for auto-sub- 
> delegation that produces reasonable results in common cases with a 
> manual override so that if you don't like the results, you can always 
> do it yourself.
>
> - Wes

---

From: james woodyatt <[email-masked]>
Date: Mon, 20 Jul 2009 13:32:27 -0700

On Jul 20, 2009, at 13:13, Fred Baker wrote:
> case, which is that the home router is the only router present. To  
> go beyond that, I think your document should be referring to the  

Exactly so, and I don't see a good reason yet to disturb that consensus.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 22:45:33 +0200

> However, it is too much detail for the CPE router document.

It's not a question of detail, it's a question of having the guts to  
lay down the law to the ISPs and the vendors in order to save the  
users from a crappy experience.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 20 Jul 2009 17:10:02 -0400

>> Yeah - a very detailed discussion needs to be had here - and a 
>> document to be written.  Perhaps we can have this discussion on this 
>> mailer.

>It's not a question of detail, it's a question of having the guts to
lay down the law to the ISPs and the 
>vendors in order to save the users from a crappy experience.

Then write up a draft on how to do it in complete detail, and we can
discuss it on this mailer.

- Wes

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Jul 2009 14:15:08 -0700

> discuss it on this mailer.

Actually, no. Protocols, and therefore the protocols used for the sub- 
delegation of prefixes throughout a SOHO/SMB, are the province of 6man.

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Jul 2009 14:16:21 -0700

On Jul 20, 2009, at 1:45 PM, Iljitsch van Beijnum wrote:

>> document

I'm entertaining visions of the IETF "laying down the law" to an ISP.

---

From: Fred Baker <[email-masked]>
Date: Mon, 20 Jul 2009 17:41:24 -0700

here is an example of the kind of draft I might hope 6man discussed.  
If you want, we can hack this into a better input to them.

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Jul 2009 10:05:24 +0200

>> can't use my own CPE because there is no subdelegation.

Agreed that this is a goal.
> absolutely need to specify how that's done with zero configuration.

Agreed

>   Are we ready to do that yet?  I don't believe we are.  Very happy  
> to be proven wrong about that.

Agreed that we are not ready yet.

To make progress, my work on SAM (draft-despres-sam-03) includes an  
attempt at providing a solution.
The approach will be presented at the Intarea session, Wednesday  
15:10-16:10.
The ID abstract says "... Global prefixes delegated by a zone to its  
child interfaces can be obtained by autoconfiguration, thanks to to a  
bidirectional correspondence between SAM local addresses and SAM  
global prefixes..."

See you in Stockholm to discuss it (if you have time for this subject).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Jul 2009 10:29:40 +0200

Le 21 juil. 09 à 02:41, Fred Baker a écrit :

> here is an example of the kind of draft I might hope 6man  
> discussed. If you want, we can hack this into a better input to them.
>
> <prefix-subdelegation.xml><prefix-subdelegation.txt>

A previous answer to James, with an extract below, is I believe also  
relevant.

You write in your draft "The most general case, that of assigning  
subnet numbers throughout an arbitrary complex topology, may be  
beyond algorithmic description."
The SAM approach may not be intended to deal with the "most general"  
case, but it deals already deals with a "quite general" case: multi- 
layer hierarchies, multihoming possible at each layer, flexible  
numbers of bits used at each layer.
It is also expected to remain simple and incrementally deployable.

Discussing it in Stockholm would IMHO be useful.

Regards,
RD

> De : Rémi Després <[email-masked]>
> Date : 21 juillet 2009 10:05:24 GMT+02:00
> À : james woodyatt <[email-masked]>
> Cc : IPv6 Operations <[email-masked]>
> Objet : Rép : Posted a new copy of CPE Rtr draft
>
>
>>   Are we ready to do that yet?  I don't believe we are.  Very  
>> happy to be proven wrong about that.
>
> The ID abstract says "... Global prefixes delegated by a zone to  
> its child interfaces can be obtained by autoconfiguration, thanks  
> to to a bidirectional correspondence between SAM local addresses  
> and SAM global prefixes..."

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 21 Jul 2009 09:31:45 -0400

Great start!  If you constrain the topology to a simple tree, it is
possible to sub-delegate in a reasonable fashion in the home.

- Wes 

-----Original Message-----
From: Fred Baker (fred) 
Sent: Monday, July 20, 2009 8:41 PM
To: Wes Beebee (wbeebee); Iljitsch van Beijnum; james woodyatt; Barbara
Stark
Cc: IPv6 Operations

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 21 Jul 2009 10:00:57 -1000 (HST)

On Mon, 20 Jul 2009, Fred Baker wrote:

> here is an example of the kind of draft I might hope 6man discussed. If you 
> want, we can hack this into a better input to them.

A network of single-homed but multiply cascaded routers is significantly 
more common in actual usage and perhaps simpler than the multi-homed 
scenario currently described for section 2.3.

Tony
[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Jul 2009 15:18:41 -0700

np; that is a special case of that one, in which there is only one ISP  
and therefore one CPE router. What I was trying to go for was the most  
complex model I could think of a home that actually ran (which is a  
merger of Jari Arrko's home and James Polk's home).

On Jul 21, 2009, at 1:00 PM, Antonio Querubin wrote:

>> discussed. If youwant, we can hack this into a better input to them.
>
> A network of single-homed but multiply cascaded routers is  
> significantlymore common in actual usage and perhaps simpler than  
> the multi-homedscenario currently described for section 2.3.
>
> Tony
> [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Jul 2009 08:19:20 -0700

Hi,

Tunnel MTU issues came up in both the 6rd and CPE router
discussions today. As near as I can tell, the issues are
not going to go away and will keep coming up over and
over again the more we talk about tunneling.

SEAL is proposal that has a real chance of cleaning up
the issues once and for all. I will be briefing the
updates to the document at the intarea meeting tomorrow,
but in the meantime the draft is here:

http://tools.ietf.org/html/draft-templin-intarea-seal-05

Comments or questions welcome,

Fred
[email-masked]

---

From: Mark Townsley <[email-masked]>
Date: Tue, 28 Jul 2009 19:44:00 +0200

Thanks for keeping us on our toes Fred!

I'd like to clarify of course that some of the MTU issues we discussed 
were not specific to tunneling, but to mismatched MTUs on a home LAN vs. 
WAN interface in general. The extra 20 bytes of a 6rd or 6to4 
encapsulation isn't significant when trying to solve support of 9K jumbo 
frames and standard 1500 byte ethernet MTUs in the same network.

Tunneling does affect MTU, no doubt. I'll point out that with 6rd, the 
deployment space of the tunnel is limited, making it dramatically easier 
to "tune" than with 6to4. Unlike SEAL, this is still essentially an 
operator tweaked value in the current deployment model.

- Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 20:03:42 +0200

On 28 jul 2009, at 19:44, Mark Townsley wrote:

> I'd like to clarify of course that some of the MTU issues we  
> discussed were not specific to tunneling, but to mismatched MTUs on  
> a home LAN vs. WAN interface in general.

In IPv6 you can easily broadcast your WAN MTU in RAs on the LAN. So if  
your WAN has 1337 you simply have an MTU option with "1337" in RAs  
that are sent out on the LAN side.

> The extra 20 bytes of a 6rd or 6to4

With 6to4 most implementations simply use 1280.

> encapsulation isn't significant when trying to solve support of 9K  
> jumbo frames and standard 1500 byte ethernet MTUs in the same network.

I have an expired draft that solves exactly that issue:

http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-02

I intend to bring it back to life in a much improved incarnation at  
some point, didn't get that done before this meeting.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 28 Jul 2009 14:15:35 -0400

Is there a BCP draft out there that surveys all of the MTU
issues/solutions and makes some recommendations for different use cases?

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Templin, Fred L
Sent: Tuesday, July 28, 2009 11:19 AM
To: IPv6 Operations
Subject: Tunnel MTU

Hi,

Tunnel MTU issues came up in both the 6rd and CPE router discussions
today. As near as I can tell, the issues are not going to go away and
will keep coming up over and over again the more we talk about
tunneling.

SEAL is proposal that has a real chance of cleaning up the issues once
and for all. I will be briefing the updates to the document at the
intarea meeting tomorrow, but in the meantime the draft is here:

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Jul 2009 11:52:00 -0700

Mark,

> From: Mark Townsley [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 10:44 AM
> To: Templin, Fred L
> Cc: IPv6 Operations
> Subject: Re: Tunnel MTU
> 
> 
jumbo
> frames and standard 1500 byte ethernet MTUs in the same network.

Two issues here. First, if the home link has a 9KB MTU
and the CPE advertises something like 1480, all nodes
on the home link will be stuck using a 1480 MTU even
for communications that never leave the link. At least
that's how it is in current IPv6 implementations.

Secondly, if the home network has multiple links (connected
by routers), the links that are deep inside of the home
network will not see the CPE router's MTU advertisement
and will continue using the native link size (e.g., 1500
bytes). Their 1500 packets will then of course be dropped
by the CPE router and an annoying ICMP PTB sent back to
trigger an even more annoying retransmission.

> operator tweaked value in the current deployment model.

As I said in the meeting, the tunnel gives you a
configuration knob with 1280 at the "safe" extreme
and 1480 at the "living dangerous" extreme (unless
of course you know that *all* links in the ISP network
configure a larger MTU). Another concern is what to
do about a misconfigured link somewhere in the ISP
network (e.g., it sets an MTU of 900 when it meant
to set 9KB). SEAL will ride over that without loss
and will even help identify the degenerate link so
it can be fixed. Without SEAL, setting a static MTU
even as small as 1280 causes undetected fragmentation
that can lead to severe problems especially when we
have anycast in the mix.

To go one step further, let's say we have home network
A and home network B with 9KB links behind CPE routers
running 6RD over an ISP network that is known to include
1500 links. With SEAL, nodes in home network A can send
9KB IPv6 packets to nodes in home network B *even though
the ISP network only supports 1500*. For that matter,
SEAL can also support IPv6 jumbograms (>64KB) over the
ISP network for those home users that truly want to push
the limits.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Jul 2009 11:57:13 -0700

Iljitsch,

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 11:04 AM
> To: Mark Townsley
> Cc: Templin, Fred L; IPv6 Operations
> Subject: Re: Tunnel MTU
> 

Not good unless you want to dumb down the MTU on the
LAN side even for communications local to the home
network.

> With 6to4 most implementations simply use 1280.

...and *pray* that it won't fragment.

> some point, didn't get that done before this meeting.

Is it going to require updates to all routers and hosts,
as well as IPv6 specs to be updated?

Fred

---

From: Mark Townsley <[email-masked]>
Date: Tue, 28 Jul 2009 21:13:37 +0200

Templin, Fred L wrote:
>> were not specific to tunneling, but to mismatched MTUs on a home LAN
>>     
> vs.
>   
These two problems are present with or without tunneling. Taking a 1500 
MTU down to 1480 isn't exacerbating the fundamental problem here.  1480 
& 9000 vs. 1500 & 9000 is effectively the same problem space.
>> deployment space of the tunnel is limited, making it dramatically
>>     
> easier
>   
> configure a larger MTU).
Yes, this is a very good illustration, Fred. This is effectively what we 
are offering with 6rd - a knob.
>  Another concern is what to
Isn't this a general advantage of SEAL? That is, tunnels aside, SEAL 
aims to solve MTU mismatch problems. Tunnels by their definition have 
the *potential* to create an MTU mismatch, but the scope of SEAL is 
beyond just tunneling.
> ISP network for those home users that truly want to push
Again - all neat stuff, but tunneling is but one case where MTUs are 
mismatched. In most of the cases you list here, the mismatch is more 
inherent in the link capabilities or configuration of those links by an SP.

If your point is to identify SEAL as potentially useful in cases where 
tunnels are used, I think you have succeeded. But, I do see that as a 
separable issue from 6rd itself.... If I heard you correctly at the mic 
today, you do as well, which I think is the right way to tackle each 
problem.

- Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Jul 2009 12:16:17 -0700

Wes,

RFC4459 documents "MTU and Fragmentation Issues with
In-the-Network Tunneling". I'm not aware of a specific
use case analysis, but SEAL offers three distinct "modes"
of operation geared toward anticipated use cases:

- SEAL with Fragmentation Sensing (SEAL-FS) is designed
  for performance-intensive core routers connected to
  robust links and provides a minimal mechanism for
  delivering effective path MTU feedback to the source.

- SEAL with Traffic Engineering (SEAL-TE) supports
  controlled segmentation and reassembly between routers
  closer to the edges such that a desirable path MTU
  (e.g., 1500 bytes) can be supported in low-to-moderate
  speed networks (e.g., an ISP network) and truly large
  packets (e.g., 1MB) can be supported in environments
  such as bulk transfer intensive data centers

- SEAL with Reliability Extensions (SEAL-RE) performs the
  same operations as SEAL-TE but also adds an ARQ capability
  as well as an integrity check vector that can detect errors
  missed by the link layer CRC. Example uses are mobile ad
  hoc networks on links with non-negligible interference
  characteristics and on aviation data links with both low
  data rates and high bit error rates.

(Hey - I think I just wrote a use-case document!)

Fred

> From: Wes Beebee (wbeebee) [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 11:16 AM
> To: Templin, Fred L; IPv6 Operations
> Subject: RE: Tunnel MTU
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 21:22:46 +0200

> Is it going to require updates to all routers and hosts,

Only the ones that want to send packets larger than the IPvX-over-...  
RFC allows without manually configuring a non-standard MTU.

> as well as IPv6 specs to be updated?

No, just a few new ND/RA options and some ARP hackery when applied to  
IPv4.

The point is that if a vendor ships a NIC capable of 9000-byte  
ethernet packets, the system using that NIC will send 9000-byte  
packets to other systems with the same capability, but send regular  
1500-byte packets to systems that don't implement the new stuff. And  
2250-byte packets to systems that support 2250 bytes etc. As a bonus,  
it's possible to let routers indicate in RAs that jumboframes are  
possible even if other systems don't implement the new stuff so that  
you can work together with older boxes that do jumbos but not the new  
options.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Jul 2009 12:38:28 -0700

Hi Mark,

> Sent: Tuesday, July 28, 2009 12:14 PM
> To: Templin, Fred L
> Cc: IPv6 Operations
> Subject: Re: Tunnel MTU
> 
> Templin, Fred L wrote:
> > Mark,
> >
> >
discussed
> & 9000 vs. 1500 & 9000 is effectively the same problem space.

Well, with SEAL you can get the 9KB's through even if there

> are offering with 6rd - a knob.

Agreed.

> the *potential* to create an MTU mismatch, but the scope of SEAL is

SEAL can be used end-to-end, yes.

> today, you do as well, which I think is the right way to tackle each

Correct - I am not suggesting any of this for the "base"
6rd document at this time. I do however think the base
document would benefit from a short 2-3 sentence paragraph
noting the limitations.

I am however seeing the potential for a follow-on document
that examines more advanced scenarios, e.g., for ISP
networks that want to partition themselves internally.
I have in mind something of a "6rd++" that might better
serve those uses.

Fred

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 29 Jul 2009 09:41:54 +0200 (CEST)

On Tue, 28 Jul 2009, Iljitsch van Beijnum wrote:

>> I'd like to clarify of course that some of the MTU issues we discussed were 
>> not specific to tunneling, but to mismatched MTUs on a home LAN vs. WAN 
>> interface in general.
>
> In IPv6 you can easily broadcast your WAN MTU in RAs on the LAN. So if your 
> WAN has 1337 you simply have an MTU option with "1337" in RAs that are sent 
> out on the LAN side.
>
> I intend to bring it back to life in a much improved incarnation at some 
> point, didn't get that done before this meeting.

I somehow lost the in the discusion:

According the path-MTU discovery process should work this way: the CPE 
(and subsequent routers) should notifiy the sender (with ICMPv6 packet too 
big message) to reduce MTU if the sender wants to send something over the 
WAN links (including tunnels).

So actual path-MTU may differ by destinations.

Actually the problem can be find out the sensible MTU for tunnels? Are we 
discussing the this value?

Or we are discussing something better than PMTUD?

Best Regards,
 		Janos

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Jul 2009 02:06:17 -0700

Janos,

> From: Mohacsi Janos [mailto:[email-masked]]
> Sent: Wednesday, July 29, 2009 12:42 AM
> To: Iljitsch van Beijnum
> Cc: Mark Townsley; Templin, Fred L; IPv6 Operations
> Subject: Re: Tunnel MTU
> 
> 
> 
> 
discussed were
jumbo
> > I intend to bring it back to life in a much improved incarnation at
some
> Or we are discussing something better than PMTUD?

In the case of SEAL, I am talking about something better
than PMTUD.

Fred