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

From: Ole Troan <[email-masked]>
Date: Fri, 8 Jan 2010 12:13:53 +0100

Mark,

apologies for the delay. catching up after Christmas.

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

would you be happier with the following text?

   WLL-1:  If the WAN interface supports Ethernet encapsulation, then
           the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464].

   WLL-2:  If the WAN interface supports PPP encapsulation:

           (a)  The IPv6 CE router MUST support IPv6 over PPP [RFC5072]
                and PPPoE [RFC2516].

           (b)  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.

Best regards,
Ole

---

From: <[email-masked]>
Date: Fri, 8 Jan 2010 12:36:14 +0100

sounds good to me.

Olaf 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Ole Troan
> Gesendet: Freitag, 8. Januar 2010 12:14
> An: Mark Smith
> Cc: Fred Baker; IPv6 Operations
> Betreff: Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt
> 
> Mark,
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Jan 2010 12:58:34 +0100

Mark et al,

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

with multiple suggestions and comments on this thread. I've tried to wordsmith two suggestions. the first one saying nothing about the hint to the delegating router. it is after all only a weak may in rfc3633 and most service providers would most likely just ignore the hint anyway. the second, clearer text what the hint should be and also clarify that it is only a hint.

can we get consensus on one of these?

   WPD-1a:  The IPv6 CE router MUST support DHCP prefix delegation
           requesting router behavior as specified in [RFC3633] (IA_PD
           option).

   WPD-1b:

           (a)  The IPv6 CE router MUST support DHCP prefix delegation
                requesting router behavior as specified in [RFC3633]
                (IA_PD option).

           (b)  The IPv6 CE router MAY indicate as a hint to the
                delegating router the size of the prefix it requires.
                If so, it MUST ask for a prefix large enough to assign
                one /64 for each of its interfaces rounded up to the
                nearest nibble and MUST be configurable to ask for more.
                The IPv6 CE router MUST be prepared to accept a
                delegated prefix size different from what is given in
                the hint.

Best regards,
Ole

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jan 2010 13:05:33 +0100

Hi,

>                 as independent of each other and start and terminate

I'm a bit confused about "MUST support ... PPPoE".  What if the interface
does PPP, but not "Ethernet" underneath?  As in (gasp) PPP-over-ISDN?

Besides that, I like it.

gert
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Jan 2010 13:24:00 +0100

Gert,

> does PPP, but not "Ethernet" underneath?  As in (gasp) PPP-over-ISDN?

good point. can you propose some text?

cheers,
Ole

---

From: Marco Hogewoning <[email-masked]>
Date: Fri, 8 Jan 2010 13:22:51 +0100

>                as independent of each other and start and terminate

This by the way is a nice one...I agree with the proposed text, but operationally we encountered some nice race conditions on this which you might want to catch in later revisions.

(For reference we run a modest install base of about 300k DSL lines, mostly on PPPoA.)

Ocassionally it happens that the IPCP gets interrupted because of packetloss causing echos to get dropped or it fails to establish NCP at all (lack of avaiable addresses in the free pool for instance).

Now on normal occasions from a customer perspective this means the line is broken and what usually happens (all major vendors) is that the CPE automatically tries to reopen either by starting IPCP again or even dropping the PPP completely and start from scratch.

While doing tests with IPv6 in a dual-stack environment we found a race condition in which the IPCP fails and the IPv6CP didn't, given IPv6 is not well spread these days it caused the customers to phone support because it felt "their line was broken" as they coudn't reach about 99.99% of the internet. Technically this behavior is correct in respect to the draft, IPCP and IPv6CP is completely seperated it out. However what we observed is that some vendors (including major ones like Cisco) fail to re-establish a working IPv4 connection.

Now there are always multiple sides to every story because we did find a situation where the CPE tried to reopen IPCP but our access box (JUNOSe) kept rejecting this until the whole PPP session was killed and rebuild., I also seen situations where the CPE was perfectly happy with the IPv6CP only connection and didn't even tried to re-establish an IPv4 connection.

I'm not sure how to handle this, the text in the draft is correct in the sense that you want it to be seperate, but in real life deployments, especially during the transitioning phase you, really want IPv4 to work, even it would mean to break down a working IPv6 link.

MarcoH

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Jan 2010 13:29:19 +0100

Mark,

> On Fri, 18 Dec 2009 09:09:21 -0800
> Fred Baker <[email-masked]> wrote:
> 
>> 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...
>> 
> 
> 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)

is not the following (reformatted) requirement not clear enough?

W-1:  When the router is attached to the WAN interface link it MUST
         act as an IPv6 host for the purposes of stateless or stateful
         interface address assignment ([RFC4862]/[RFC3315]).  The router
         MUST act as a requesting router for the purposes of DHCP prefix
         delegation ([RFC3633]).

"acting as a host" is the key here. feel free to suggest better text if you don't think that's clear enough.

the WAN interface which is a host for some purposes and a router for others is stretching the definitions in RFC4861 already. having an interface which can do both RS and RA at the same time would be stretching it too far. I don't know of any service provider either who would like to see RAs from an IPv6 CE router.

cheers,
Ole

---

From: Eduard Metz <[email-masked]>
Date: Fri, 8 Jan 2010 13:46:50 +0100

I experienced the same confusion, this was suggested in an earlier in
this discussion, which to me seems a good alternative for WLL-2 below:
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 start and
terminate independently.

With regard to WLL-1, should this not be " If the WAN interface
supports Ethernet encapsulation, then the IPv6 CE router MUST support
IPv6 over Ethernet  [RFC2464] or IPv6 over PPP(oE) [RFC2516]" ?

cheers, Eduard

---

From: Eduard Metz <[email-masked]>
Date: Fri, 8 Jan 2010 13:58:36 +0100

>                delegated prefix size different from what is given in

This may be getting a bit to fuzzy. I'd prefer something more along
the lines of the original statement. Assuming the intention is to
ensure that each IPv6 interface in the CE router can be configured
with a /64, should the requirement not be that the CE router does not
request (or hint for) a prefix that is too small? (without going into
saying how large it actually should be)

Maybe this has been discussed before, but what is the desired
behaviour of the CE router in case the delegated prefix actually is
too small to assign a /64 to each of its interfaces?

cheers, Eduard

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Jan 2010 14:38:22 +0100 (CET)

On Fri, 8 Jan 2010, Eduard Metz wrote:

> With regard to WLL-1, should this not be " If the WAN interface supports 
> Ethernet encapsulation, then the IPv6 CE router MUST support IPv6 over 
> Ethernet [RFC2464] or IPv6 over PPP(oE) [RFC2516]" ?

It should support BOTH then, not just one of them (which I think is the 
intention of the document in its current state).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jan 2010 14:46:17 +0100

Hi,

> intention of the document in its current state).

What's wrong with a CPE that doesn't support PPPoE for IPv4?  Wouldn't
it be acceptable then to not-support PPPoE for IPv6 either?

There might be "pure ethernet" CPEs out there, with no PPP stack in them
(my guess would be that cable CPEs do "Ethernet encapsulation/framing" but
not "PPPoE").

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jan 2010 14:44:17 +0100

Hi,

> good point. can you propose some text?

Bah...  but let me try.  I'm not completely sure what we *are* trying to
say, especially given "Ethernet" vs. "PPPoE".  But let's try (also
taking MarcoH's point into account):

  WLL-1:  If the WAN interface supports non-PPPoE Ethernet encapsulation, 
          then the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464].

          (a)  The IPv6 CE router MUST support IPv6 over PPP [RFC5072].

          (b)  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.  It SHOULD be configurable to restart the
               whole PPP session in the case of one NCP consistently 
               failing to come up.

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Jan 2010 15:11:46 +0100 (CET)

> it be acceptable then to not-support PPPoE for IPv6 either?

Absolutely, but I don't think it's acceptable to have a CPE that only 
supports IPv6 PPPoE, and doesn't support it natively. This is what I read 
the original text to want, and I'm fine with that. I'm disagreeing with 
any text that implies that native IPv6 support is optional.

I now read that my reply could be interpreted that I was saying the 
current text says that native is optional, this is not the case. As I read 
the text, it's saying that IPv6 native is mandatory, and PPPoE is 
optional, and then says what is required in case of PPPoE support. This is 
good.

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jan 2010 15:18:01 +0100

Hi,

> any text that implies that native IPv6 support is optional.

Well, what's "native" in a CPE that has a built-in DSL modem which only
supports PPPoE encapsulation...?

What I want to see is "if it can do encapsulation X (at all), it should
be able to do PPP-over-X, as per RFC [Z]".

I do not see strong need to mandate "it must do encapsulation A, B and C", 
because the target customer base might not have or want "A" and "C"...

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Jan 2010 15:22:16 +0100 (CET)

> supports PPPoE encapsulation...?

If it supports 1483bridged then it supports ethernet and then it should 
support native IPv6 over that. If it only supports PPPoA, then it's not 
ethernet and then it's fine to only support PPP. The original text is 
still fine as far as I see.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 8 Jan 2010 09:10:53 -0600

>This may be getting a bit to fuzzy. I'd prefer something more along the lines of the original statement.
>Assuming the intention is to ensure that each IPv6 interface in the CE router can be configured with a
> /64, should the requirement not be that the CE router does not request (or hint for) a prefix that is
> too small? (without going into saying how large it actually should be)
>
> Maybe this has been discussed before, but what is the desired behaviour of the CE router in case the
> delegated prefix actually is too small to assign a /64 to each of its interfaces?

I suspect that the behavior for a too small prefix would be vendor-dependent as I don't think that we could end up with recommending a specific behavior that would pass IETF consensus.  However, I think that asking for a prefix large enough to do SLAAC, even if you don't get it, is behavior that is completely reasonable and the right thing to do - but shouldn't be mandated.  Stating this hint in this document is a heads-up to service providers to expect that some CE routers may have this behavior.  Therefore, I agree with the text of WPD-1b as is - subject to possibly breaking up MAYs and MUSTs as we're doing elsewhere in the document.

- Wes

---

From: Eduard Metz <[email-masked]>
Date: Fri, 8 Jan 2010 16:17:57 +0100

Is the intention really to mandate "native IPv6 support" over the
link-layer of the WAN interface? (2492 in the below case?) If so this
could be captured in a generic statement (assuming other documents
specify IPv6overX).

Specifically for Ethernet there are two common models for broadband
access, the 'native' model en the PPP(oE) model. Why would this draft
mandate one if it is already known upfront many will be using the
other?

cheers, Eduard

On Fri, Jan 8, 2010 at 3:22 PM, Mikael Abrahamsson <[email-masked]> wrote:
> ethernet and then it's fine to only support PPP. The original text is still
> fine as far as I see.
>
> --

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Jan 2010 08:58:51 -0800

Ole,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Friday, January 08, 2010 4:29 AM
> To: Mark Smith
> Cc: IPv6 Operations
> Subject: Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt
> 
> Mark,
> 
> the WAN interface which is a host for some purposes and a router for others is stretching the
> definitions in RFC4861 already. having an interface which can do both RS and RA at the same time
> would be stretching it too far.

Why can't a CPE router send unicast RAs to other CPE
routers as long as they are not malicious and do not
in any way conflict with the RAs sent by SP routers?

Fred
[email-masked]

> I don't know of any service provider either who would like to see RAs
> from an IPv6 CE router.
> 
> cheers,
> Ole

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jan 2010 18:13:47 +0100

Hi,

> in any way conflict with the RAs sent by SP routers?

How do you verify those are not malicious?

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Jan 2010 09:33:05 -0800

> From: Gert Doering [mailto:[email-masked]]
> Sent: Friday, January 08, 2010 9:14 AM
> To: Templin, Fred L
> Cc: Ole Troan; Mark Smith; IPv6 Operations

The sending CPE has to supply sufficient credentials to
prove that it is authorized to advertise a given set of
prefixes.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Jan 2010 08:52:31 +1300

>                whole PPP session in the case of one NCP consistently 

In any case, it's best to avoid a normative reference to PPPoE [RFC2516],
because that is not an IETF standard, so will require some extra
bureaucracy at the IESG approval stage.

    Brian

---

From: Eduard Metz <[email-masked]>
Date: Fri, 8 Jan 2010 21:05:17 +0100

> I suspect that the behavior for a too small prefix would be vendor-dependent as I don't think that we could end up with recommending a specific behavior that would pass IETF consensus.  However, I…

So it's a hint that some devices may provide hints ;-) .. this may be too subtle

I'd suggest to make it a more concise requirement. The first two parts
to me are the core:
The first part of WPD-1b describes the option of providing a hint on
prefix size, this is already in RFC3633, but it can be restated here.
The second part of WPD-1b relates the prefix hint to the CE
interfaces. With regard to this I meant to say that -if- the CE router
provides a hint, it should not hint for a prefix smaller than required
to assign a /64 to each of its interfaces. So I think we agree here.

The rest I think can (or even should) be left out:
The third part seems to suggest a default value for hinted prefix
size, based on number of interfaces, or manual configuration. This
could be included as an example of how the prefix size could be
determined, I do not think it should be part of the requirement.
The last part of -1b is already described in RFC3633, for clarity may
be good to restate, but not necessary.

A question: is WPD-1b meant to apply to all DHCP messages in which the
prefix length is specified by the requesting (CE) router? Or just the
case of initial boot (no previously assigned prefix). If a prefix
previously was assigned, I assume the CE router should include this as
a hint, and not provide a hint according to WPD-1b?

/Eduard

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 8 Jan 2010 15:10:54 -0600

> A question: is WPD-1b meant to apply to all DHCP messages in which the
prefix length is specified by
> the requesting (CE) router? Or just the case of initial boot (no
previously assigned prefix). If a
> prefix previously was assigned, I assume the CE router should include
this as a hint, and not provide a
> hint according to WPD-1b?

Actually, I think that the CE router should provide the WPD-1b value as
the hint either when first requesting it or renewing - and the SP is
free to provide a different answer the second time.

- Wes

---

From: Eduard Metz <[email-masked]>
Date: Fri, 8 Jan 2010 22:40:58 +0100

> free to provide a different answer the second time.

Consider a CE with 2 LAN interfaces, it hints a prefix length of /60.
The delegated prefix is /48. At renew the CE again hints at /60??

Or should be receipt of the /48 be considered a "configuration" of a
larger prefix?

Still thinking this should not be part of the requirement, it's
distracting from core intent of the requirement (which is to request a
sufficiently large prefix).

/Eduard

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 8 Jan 2010 15:51:14 -0600

larger prefix?

Imagine a SP who gave out a /48 and decides later that they want to
reclaim that space...

How will the SP know what the CE really needs unless the CE hints at
only what it needs?

Of course, most SP's will probably ignore what the CE hints at and will
give what their internal company policy states.  But imagine an extra
nice SP that wants to be kind to the CE by doing what it wants and a CE
that wants to be as kind back to the SP by only asking for what it
needs.  

> Still thinking this should not be part of the requirement, it's
distracting from core intent of the
> requirement (which is to request a sufficiently large prefix).

Agreed that it's not the core issue here.

---

From: Gert Doering <[email-masked]>
Date: Fri, 8 Jan 2010 23:34:34 +0100

Hi,

> prove that it is authorized to advertise a given set of

Which is, as far as I understand, not part of any currently 
standardized RAs.  Are there any drafts specifying this?

So while I can see CPE-to-CPE RA as "nice to have", I can't really see 
the relevance for the WGLC of *this* document.

Gert Doering

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Jan 2010 14:50:55 -0800

Gert,

> Sent: Friday, January 08, 2010 2:35 PM
> To: Templin, Fred L
> Cc: Gert Doering; Ole Troan; Mark Smith; IPv6 Operations

RFC3971 is the primary example I had in mind.

Fred

---

From: Ole Troan <[email-masked]>
Date: Sat, 9 Jan 2010 09:00:53 +0100

> bureaucracy at the IESG approval stage.

PPPoE is _just_ PPP from an IPv6 point of view.
with Brian's comment in mind. I would be inclined to delete the
reference to PPPoE in WLL-2.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Sat, 9 Jan 2010 11:54:30 +0100

Hi,

> RFC3971 is the primary example I had in mind.

OK, on re-reading 3971, I agree that it could work if the ISP hands out
certificates to the individual routers that cover exactly the IPv6 network
that the ISP has assigned to this router (and it would imply that the
IPv6 assignment is mostly statical, or you get lots of certificat churn
otherwise).  

So the RAs received from "my neighbours" could indeed be verified against
the ISP CA.

Still not something I expect to see any time soon...

Gert Doering

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Jan 2010 23:18:28 +1030

Hi Fred,

On Fri, 8 Jan 2010 08:58:51 -0800

> in any way conflict with the RAs sent by SP routers?

I think on some networks that could have multicast traffic volume
related scaling issues. It's quite possible to build single Ethernet
link layers using DSL that have 100s or 1000s of CPE attached. It also
seems a bit redundant to have the CPEs fully aware of all their
neighbours' downstream prefixes, yet be unlikely to use those routes
very often.

My thinking has been that a prefix-redirect option, with appropriate
rate-limits, issued by the SP router toward the originating CPE, would
be a more scalable and less resource consuming way to achieve optimal
CPE-to-CPE forwarding.

As a prefix-redirect option doesn't currently exist, it'd be both
redundant and resource consuming for the SP router to continue to send
prefix-redirects to CPE that wasn't paying attention to them. One
thought I'd had was if the CPE were issuing RAs, they announce a
prefix-redirect capability option. The SP router would then know it
could send prefix-redirects to the announcing CPE. This CPE router
state in the SP router could also be used to track per-CPE
prefix-redirect rate limits, rather than having a global
prefix-redirect rate limit.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 9 Jan 2010 16:16:10 +0100 (CET)

> neighbours' downstream prefixes, yet be unlikely to use those routes

I think no ISP will ever build a network that allows for local routing 
like that (at least not intentionally). So far ISPs do not want customers 
to talk L2 directly with each other, but instead want to do the routing 
between customers (mostly for security reasons). I therefore think it's a 
moot point to try to drive any standard that by a lot of security measures 
tries to solve this in the CPE. It just won't be deployed because of its 
complexity.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Jan 2010 08:37:34 +1300

On 2010-01-10 04:16, Mikael Abrahamsson wrote:
> like that (at least not intentionally). So far ISPs do not want
> customers to talk L2 directly with each other, but instead want to do
> the routing between customers (mostly for security reasons). I therefore
> think it's a moot point to try to drive any standard that by a lot of
> security measures tries to solve this in the CPE. It just won't be
> deployed because of its complexity.

Especially since the amount of such local traffic seems likely to
be tiny, and therefore not worth optimising. Does anyone have any
actual data on this?

     Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 Jan 2010 10:08:58 +1030

Hi Mikael,

On Sat, 9 Jan 2010 16:16:10 +0100 (CET)
Mikael Abrahamsson <[email-masked]> wrote:

> like that (at least not intentionally).

Up until the end of November I worked at one, and I would have like to
have built something like this.

In this ADSL scenario, geographic layer 2 customer aggregation points
weren't always layer 3 traffic aggregation points. It's a trade off
between a larger number of smaller layer 3 devices, one or two at each
layer 2 geographic site, or a more centralised and offsite layer 3
infrastructure, handling traffic for multiple layer 2 geographic sites.
How many layer 2 sites you aggregate together for layer 3 services is
determined by the geography of your customer base, how many and the
size of the layer 3 devices you want to operate and the costs of
backhaul bandwidth between the layer 2 sites and the chosen layer 3
aggregation site. In this scenario, backhauling all inter-customer
traffic to a more central locations where the layer 3 infrastructure
was located, even though customers were local layer 2 peers seems
redundant to me. 

The fundamental difference here verses what's been built in the past
with IPv4 is that with the IPv6 addressing model of allocating
relatively large prefixes to SP customers, and IPv6's multicast
neighbour discovery (i.e. more scalable than IPv4's broadcast address
based resolution), there are scenarios where 100s if not 1000s of
routers may be link layer peers. The cost difference between layer 2
forwarding and layer 3 forwarding also encourages minimising the layer
3 resources.

In the IPv4+NAT world, while the CPE were routers, the prefixes behind
them weren't unique so it fundamentally wasn't possible to have the CPE
or the SP routers make local and more intelligent forwarding decisions.
Now that IPv6 will provide customer unique prefixes, the locations
behind the customer CPE are now externally visible and therefore could
be used for more optimal and less resource consuming traffic
forwarding. Optimal traffic paths provide better quality of service to
customers, and less resource consuming traffic forwarding provides
lower costs to service providers.

> So far ISPs do not want customers 
> between customers (mostly for security reasons).

"security reasons" is a nice generic term, but it doesn't really
explain anything. What specific "security reasons"? What if an ISP
doesn't want to provide "security", and would rather just be a dumb bit
pipe for their customers?

I also think it may not be that ISPs haven't wanted their customers to
talk L2 directly with each other, it think it's probably because they
haven't been able to. They've had legacy PPPoE infrastructures which
force hair pinning of traffic between layer 2 adjacent customer, or the
nature of the link layer technology, e.g. cable or ATM, hair pins the
traffic anyway and may not support simple link layer peer-to-peer
traffic exchange, without something like NHRP or setting up switched
virtual circuits.

> I therefore think it's a 

If a generic "complexity" argument is going to be used, then I'd argue
that a prefix-redirect mechanism is much much simpler than PPPoE, PPP or
DHCP. Single packet format, simple processing. It's not really any more
complex that host-redirects and they're not complicated.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 Jan 2010 10:28:30 +1030

Hi Brian,

On Sun, 10 Jan 2010 08:37:34 +1300

> be tiny, and therefore not worth optimising. Does anyone have any

I don't - my motivation has been to look at it as a missed
opportunity for better traffic locality, if the mechanism to do it was
simple enough.

It seems to me that peer selection in peer-to-peer protocols could be
improved by measuring the latency between peers (e.g. by looking at
the SRTT values of the TCP connections to the peers), as lower
latency peers would also typically have more bandwidth between them. If
peer-to-peer as a content distribution method continues to increase, I
think there is or will be increasing value in having customer CPE being
more aware of more direct paths to local destinations.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Jan 2010 14:07:16 +1300

> more aware of more direct paths to local destinations.

That's true in theory. But since what we are aiming at with the current
draft is the first round of CPE requirements based on well established
specs, it seems out of scope. Probably a topic for discussion on
draft-wbeebee-v6ops-ipv6-cpe-router-bis?

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 Jan 2010 12:40:56 +1030

Hi Brian,

On Sun, 10 Jan 2010 14:07:16 +1300

> draft-wbeebee-v6ops-ipv6-cpe-router-bis?

Certainly the whole prefix-redirect idea is out of scope for this
draft. The only area where I thought there could be related issues was
if the CPE didn't issue RAs, then RAs wouldn't be able to be used for a 
a prefix-redirect capability announcement (if that is a good idea in
itself). Thinking about it a bit more, a Neighbor Announcement option
might be a better place to express such a capability, and wouldn't
require CPE to issue RAs towards the SP router.

On a related note, I think some of the data in section 3.1.  "Reduced
Cross-domain Traffic" of "Improving Peer Selection in Peer-to-peer
Applications: Myths vs. Reality" shows the value of localising traffic
for P2P architecture applications -

http://tools.ietf.org/id/draft-irtf-p2prg-mythbustering-00.txt

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 10 Jan 2010 09:25:30 +0100 (CET)

> forwarding and layer 3 forwarding also encourages minimising the layer

I don't agree AT ALL, rather the opposite. I'd like to see rudimentary L3 
switch quite close to the customer instead of these huge L2 clouds people 
seem to like. Customers should not be in the same broadcast domain unless 
quite a lot of security measures are taken (MAC rewrite etc). Basically 
everything the customer can set themselves needs to be controlled in case 
of shared L2.

The "security" I am talking about is the BCP38/SAVI kind, not anything 
else. Doing that kind of security (defying spoofing, man in the middle, 
etc) requires a lot of L2/L3 magic in a big L2 network, I'd rather avoid 
that.

> pipe for their customers?

They still need to do basic BCP38.

> traffic exchange, without something like NHRP or setting up switched

Read my previous posts, I come from an ETTH background as of 10 years and 
there we had shared L2 by means of L2 switches in every basement. When I 
designed ADSL I did it with single vlan per customer and L3 switch in each 
PoP.

> complex that host-redirects and they're not complicated.

I don't see how this easily can be done and still adhere to BCP38. Guess 
it would involve a lot more SAVI requirements on the L2 device aggregating 
the customers.

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 Jan 2010 21:11:36 +1030

On Sun, 10 Jan 2010 09:25:30 +0100 (CET)

> it would involve a lot more SAVI requirements on the L2 device aggregating 

All fair points.

Hair pinning traffic via a router to perform the functions you
mention is one way to achieve these security goals. Having the layer 2
device, the point-of-interconnect for the customer, perform them is
another. While I agree with you about the layer violations of having
layer 2 devices looking at layer 3 fields, I also think that these
security functions should be performed as close as possible to the
customer. If it's bad traffic, it should be dropped as soon as possible

My argument is that if an SP chooses to have the layer 2 edge
device perform those security functions, then there is an opportunity
for more optimal traffic forwarding via a mechanism like a
prefix-redirect. You may not like that design, but you might not have
to be making decisions about the tradeoffs between backhaul cost, capex
and opex of aggregated-vs-per-POP layer 3 and the influence over
customer density and geography that other SPs around the world have to
make.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 10 Jan 2010 11:48:06 +0100 (CET)

> customer density and geography that other SPs around the world have to

Since some ISPs seem fine with backhauling their PPPoE traffic to a single 
place in a whole nation, let's (as said in another mail) postpone these 
hypothetical optimizations to a later update of the document. Right now we 
need to get IPv6 out the door at all, and still do it securely. I'd rather 
have the vendors implement the things we have in the document right now, 
than adding more things in there and postponing deployment further.

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 Jan 2010 21:49:00 +1030

On Sun, 10 Jan 2010 11:48:06 +0100 (CET)

> than adding more things in there and postponing deployment further.

I agree, the draft shouldn't be held up. I wasn't ever saying that this
prefix-redirect idea should be in this draft, only that CPE RAs towards
the SP might be a place that such a supported capability could be
announced, which of course wouldn't be possible if this draft stopped
CPE from issuing RAs.

Thinking about it a bit further, I think a Neighbor Announcement option
might be an alternative and possibly better place for this capability
announcement option, should the idea itself have merit.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Jan 2010 08:53:33 -0800

Gert,

> Sent: Saturday, January 09, 2010 2:55 AM
> To: Templin, Fred L

What I am looking for is a way for a CE router to inject
its own PI prefixes into the service provider's routing
system. For this, the CE router would first need a way
to prove to the SP router that it owns the prefixes, and
this is the area where I am considering the use of SEND.
To your point about static assignment - yes, I expect
that the CE router would want to retain its PI prefixes
for the long term so that it would not have to renumber.

> So the RAs received from "my neighbours" could indeed be verified against

Good.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Jan 2010 09:09:01 -0800

Hi Mark,

> From: Mark Smith [mailto:[email-masked]]
> Sent: Saturday, January 09, 2010 4:48 AM
> To: Templin, Fred L
> Cc: Ole Troan; IPv6 Operations
> > > "acting as a host" is the key here. feel free to suggest better text if you don't think that's
> clear
> > > enough.
> > >
> related scaling issues.

That is why I said "unicast RAs" and not multicast ones.

> It's quite possible to build single Ethernet
> link layers using DSL that have 100s or 1000s of CPE attached.

This is consistent with the model I have in mind.

> It also

This is *not* consistent with the model I have in mind.
I only want CE routers to become aware of neighbors'
downstream prefixes on an on-demand basis; I do not
want the CE router to have to pre-populate its routing
tables with routes for all potential neighboring CEs.

> be a more scalable and less resource consuming way to achieve optimal

This is consistent with the model I have in mind.

> prefix-redirect rate limit.

Yes, I like the idea of having the SP router track
whether/not the CE router will heed the redirects.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Jan 2010 10:11:48 -0800

Mark,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Smith
> Sent: Sunday, January 10, 2010 3:19 AM
> To: Mikael Abrahamsson
> Cc: IPv6 Operations

Use of the NA instead of RA would prevent the CE router
from advertising information that would conflict with
the information advertised by SP routers. I am thinking
here about link-related information such as Reachable
Time, Retrans Timer, and those confounded M&O bits that
occur in RA messages but not NA.

One matter of concern is whether we can use NA messages
for the purpose of SEND Authorization Delegation Discovery
per RFC3971, Section 6. By my read of that section, it says
that the authorization model is used to protect Router
Discovery but it does *not* say that only RA messages (and 
not NA) must be used. Hence, I presume that we can piggyback
RFC3971 section 6 authorization delegation discovery on top
of NA messages?

James Woodyatt's disclaimer notwithstanding, does anyone
see an issue with using unsolicited, unicast NAs?

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Mon, 11 Jan 2010 19:23:31 +0100

Fred et al,

this is an interesting topic, but I believe this is new innovative work and out of scope for this draft. could we move this to a separate thread from the draft last call?

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jan 2010 10:28:09 +1030

Hi Ole,

Sorry not to get back to you sooner.

On Fri, 8 Jan 2010 12:58:34 +0100

>                 delegated prefix size different from what is given in

I'm generally happy with the above text. I think the last sentence in
(b) would be slightly better if it said "greater than" rather than
"different than".

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jan 2010 10:36:20 +1030

On Fri, 8 Jan 2010 16:17:57 +0100

> could be captured in a generic statement (assuming other documents

That was my original point. The world hasn't converged to Ethernet only
framing on access links (yet!), but the draft was dictating
mandatory IPv6 over Ethernet and PPPoE support like it had. That clause
would have made e.g. IPv6 with 3G/HSPDA WAN interfaces non-compliant
with the RFC, or somehow made vendors of this type of CPE try to
shoehorn ethernet encapsulation onto the 3G/HSPDA access interface.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 13 Jan 2010 09:42:29 -0600

"different than".

Actually, "different than" captures the scenario where the PD is a
longer prefix than the hint indicated, in which case the CPE router may
not be able to number all of the interfaces in such a way as to enable
SLAAC.  What to do in this case is unclear, and we leave it up to the
vendor.

It also captures the case where the PD is a shorter prefix than the hint
indicated, which is not really a problem for the CPE router.

- Wes

---

From: james woodyatt <[email-masked]>
Date: Wed, 13 Jan 2010 15:47:47 -0800

On Jan 11, 2010, at 10:11, Templin, Fred L wrote:
> 
> James Woodyatt's disclaimer notwithstanding, does anyone see an issue with using unsolicited, unicast NAs?

For prefix redirection?

p1. I think this is better deferred to the -bis draft.

p2. I don't think it will be practical for CPE routers to send prefix redirections to other nodes on the WAN link in neighbor advertisements.  I think default routers on the WAN link should send ICMP redirects to hosts.  The validity check on ICMP redirects are a good idea.  Even better idea in the presence of SEND.

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

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Jan 2010 12:19:37 +1030

Hi Wes,

On Wed, 13 Jan 2010 09:42:29 -0600

> SLAAC.  What to do in this case is unclear, and we leave it up to the

I'm not quite sure then I can see the value in this mechanism at all
then. I've seen this mechanism as a "Hey ISP, I really need this amount
of address space, otherwise I'm in trouble". If it's less
significant than that, and the CPE will have to deal with a smaller
prefix than requested (how is an interesting issue - interface
priorities?), then I'm not sure I can see that much value in what it
provides, other than some slightly useful information to the ISP about
how many downstream interfaces their customers' CPE has. That might be
useful to an ISP for addressing allocation purposes, although I'd think
they're being unnecessarily conservative if they're counting how many
individual subnets are required downstream of their customers' CPE.

Have I completely misunderstood the intent of this request/mechanism?

Thanks,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Thu, 14 Jan 2010 09:26:46 +0100

Mark,

> Have I completely misunderstood the intent of this request/mechanism?

it is a "MAY" and a "hint".
a typical scenario would for example be that an SP gave a /56 regardless of the hint.

does the working group feel a need to specify the case where the CE router doesn't get a large enough prefix delegated? or are we happy leaving that up to implementations. alternatives are at least "various degrees of bailing out", "NAT66", "proxy ND"...

Best regards,
Ole

---

From: Konrad Rosenbaum <[email-masked]>
Date: Thu, 14 Jan 2010 11:04:44 +0100

> a typical scenario would for example be that an SP gave a /56 regardless of

I hope /48 is more typical... ;-)

> does the working group feel a need to specify the case where the CE router
> doesn't get a large enough prefix delegated? or are we happy leaving that
> up to implementations. alternatives are at least "various degrees of
> bailing out", "NAT66", "proxy ND"...

I personally feel this should be specified. Or at the very least some 
acceptable options should be listed.

Bailing out: does this mean fe80::/10 only? Or fc00::/7 ?
Note: fe80::/10 is a major headache  for users - I don't think I can explain 
to most of my friends how to enter http://[fe80::1122:33ff:fe44:5566%1] into 
their browsers and why it is different for every CPE they use.

NAT66: first off, the draft expired. Second it does not solve the problem: it 
is not a cone NAT - it translates a /48 into another /48 (it might be adapted 
to translate /n into /n, but not into a cone NAT).

What do you mean with "proxy ND"?

For most users a web proxy might be a temporary solution to deal with a no 
delegation situation.

Question aside from this: why request only a prefix that is barely big enough 
for a /64 for each interface? There could be dozens of routers behind that 
CPE. Why not encourage to request a /48 everytime? We aren't running out of 
them any time soon.

	Konrad

---

From: Ole Troan <[email-masked]>
Date: Thu, 14 Jan 2010 11:41:10 +0100

Konrad,

> I hope /48 is more typical... ;-)

sure, that's up to the RIRs and SP policy.

> For most users a web proxy might be a temporary solution to deal with a no 

I added the other options partly tongue in cheek. the form of bailing out I had in mind was to not enable IPv6 on interfaces which the CE doesn't have addresses for. and raise the alarm.

> CPE. Why not encourage to request a /48 everytime? We aren't running out of 

it is not quite a request. it is just a hint. as such another good option is to remove the text about the hint altogether from this draft.

Best regards,
Ole