Subject: FW: WPD-6, WAA-8, and WAA-9 of draft-ietf-v6ops-ipv6-cpe-router-04

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 5 Apr 2010 08:51:40 -0500

>>This presented quite some difficulty for NTT as an operator - as they 
>>had to restrict themselves in what they could do in terms of address 
>>space conservation in order to support a strong host model CPE router 
>>- and this warning was in a previous version of the CPE router 
>>specification.  We should actively discourage people from building and

>>using strong host model CPE routers.
>
>I guess I'm missing something obvious here.
>
>An unnumbered link can only occur i.c.w. prefix delegation (otherwise 
>the CPE wouln't have any addresses at all).
>
>Now instead of assigning an address from its prefix to a virtual 
>interface, the CPE assigns the  address to the uplink interface.
>
>This allows the CPE to implement the strong host model, and doesn't 
>require any cooperation from  the ISP.
>
>So, what is wrong with that scenario?

Section 12.1 of RFC 3633 forbids it:

"the requesting router MUST NOT assign any delegated prefixes or subnets
from the delegated prefix(es) to the link through which it received the
DHCP message from the delegating router."

- Wes

---

From: Philip Homburg <[email-masked]>
Date: Mon, 05 Apr 2010 20:44:15 +0200

>DHCP message from the delegating router."

I know, but why?

I always see a MUST NOT as something that would cause major harm or
interoperability problems. But the DHCP PD RFC just says 'MUST NOT' without
giving any reason what so ever.

So maybe it is time to revisit that requirement instead of using that to 
force the weak host model onto CPEs.

---

From: Ole Troan <[email-masked]>
Date: Mon, 5 Apr 2010 21:44:17 +0200

> force the weak host model onto CPEs.

the reason for that "MUST NOT" is to prohibit path of the delegated prefix from being used on the DR - RR link. if the DR chose to use part of the delegated prefix, that would be hard for the RR to detect and could potentially conflict with the RR's own use of the delegated prefix. "delegation" implies that the DR transfers control of the prefix to the RR.

this doesn't necessarily prohibit the RR from doing what you suggest. but, I haven't understood what problem you are trying to solve. could you expand on that?

cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 05 Apr 2010 22:53:03 +0200

In your letter dated Mon, 5 Apr 2010 21:44:17 +0200 you wrote:
> the reason for that "MUST NOT" is to prohibit path of the delegated
> prefix from being used on the DR - RR link. if the DR chose to use
> part of the delegated prefix, that would be hard for the RR to
> detect and could potentially conflict with the RR's own use of the
> delegated prefix. "delegation" implies that the DR transfers control
> of the prefix to the RR.

I don't understand what you are saying. The quoted text says "the
requesting router MUST NOT assign [..]", so this a requirement on the 
requesting router.

I don't think the DR can do anything with part of the delegated prefix 
anyhow.

I'm not proposing that the DR assigns a subset out the delegated prefix
to the link, that would not work. I'm proposing that the requesting router
assigns just for itself an address from that prefix to it's WAN interface.

> this doesn't necessarily prohibit the RR from doing what you suggest.
> but, I haven't understood what problem you are trying to solve.
> could you expand on that?

The current text in draft-ietf-v6ops-ipv6-cpe-router-04 mandates the
weak host model: if the CPE gets a delegated prefix with an unnumbered WAN
link then RFC-3633 prevents it from assigning an address out of that prefix to
it's WAN interface.

I prefer to avoid unnumbered links. I think it is much less confusing if 
source addresses of error ICMPs are always addresses from the interface that
generated the error.

So I'd like the CPE to be able to assign an address from it's prefix to it's
WAN interface.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 5 Apr 2010 16:01:02 -0500

> I prefer to avoid unnumbered links. 

Unnumbered links are a deployment scenario that is highly desirable from
some operators who wish to administratively separate the link between
the SP and the CPE and the home...  They are also, in some cases, more
easily administrated from an addressing prespective than numbered links.

Your proposal would deny the SP the ability to administer their network
the way they want to.

- Wes

---

From: Philip Homburg <[email-masked]>
Date: Mon, 05 Apr 2010 23:15:16 +0200

>Your proposal would deny the SP the ability to administer their network

That is a separate issue.

The first issue is that the DHCP PD RFC doesn't allow what I'm proposing,
whether the ISP agrees or not.

The second issue, ISPs who like unnumbered links. I respect that. However,
as I said in a previous mail. The difference between assigning an address
to a virtual interface or to the WAN interface itself is almost completely
invisible to the ISP. 

So if ISPs essentially cannot tell the difference, how can it matter to them?

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Apr 2010 15:01:40 -0700

Dumb question. In an IPv6 world, we don't actually have unnumbered links; we have link-local-addressed links. The link do in fact have addresses, but they are not externally addressable/ddos-able. If you want to manage a router, you use its loop-back address, which is perhaps a ULA and therefore unroutable from neighboring (customer, upstream, or peer) networks. 

Is there a problem with the link-local-address model if an ISP would rather use it? 

Or did I miss something?

> So if ISPs essentially cannot tell the difference, how can it matter to them?

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Apr 2010 10:24:44 +0200

> source addresses of error ICMPs are always addresses from the interface that

these two paragraphs are mutually exclusive. you cannot require that an ICMP error is sourced from the interface that generated the error and at the same time require that a router use the strong host model.

/ot

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 6 Apr 2010 08:31:15 -0500

>>"the requesting router MUST NOT assign any delegated prefixes or 
>>subnets from the delegated prefix(es) to the link through which it 
>>received the DHCP message from the delegating router."
>
>I know, but why?
>
interoperability problems. 
>But the DHCP PD RFC just says 'MUST NOT' without giving any reason what
so ever.
>
>So maybe it is time to revisit that requirement instead of using that
to force the weak host 
>model onto CPEs.

The deployment that you suggest, using an address from the PD for the
WAN interface, will cause on-link determination problems for the SP
router, and will result in lack of network connectivity to the CPE
router.  Thus, yes, there will be interoperability problems.

We need to discourage CPE routers from using the strong host model in
order to ensure that we can provide network connectivity and to allow
SP's to address the network the way that they want to.

- Wes

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Apr 2010 15:42:48 +0200

In your letter dated Mon, 5 Apr 2010 15:01:40 -0700 you wrote:
>Dumb question. In an IPv6 world, we don't actually have unnumbered 
>links; we have link-local-addressed links. The link do in fact have 
>addresses, but they are not externally addressable/ddos-able. If you 
>want to manage a router, you use its loop-back address, which is perhaps 
>a ULA and therefore unroutable from neighboring (customer, upstream, or 
>peer) networks.
>
>Is there a problem with the link-local-address model if an ISP would =
>rather use it?
>
>Or did I miss something?

I've never seen a real definition of what 'unnumbered' is supposed to mean
in the context of IPv6, but I think it is assumed to mean a link that does not
have a global prefix.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 6 Apr 2010 08:50:07 -0500

>>want to manage a router, you use its loop-back address, which is 
>>perhaps a ULA and therefore unroutable from neighboring (customer, 
>>upstream, or
>>peer) networks.
>>

>>rather use it?
>>
>>Or did I miss something?
>
>I've never seen a real definition of what 'unnumbered' is supposed to
mean in the context of IPv6, >but I think it is assumed to mean a link
that does not have a global prefix.

By unnumbered, we are referring to a link that only has a link-local
address and does not have a ULA or a global prefix.  All globally-routed
traffic sourced by this interface uses a global prefix assigned to a
different interface, and thus, the device uses the weak-host model,
since the strong-host model would forbid traffic with a source address
that doesn't match any address assigned to the source interface.

- Wes

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Apr 2010 15:48:24 +0200

In your letter dated Tue, 6 Apr 2010 10:24:44 +0200 you wrote:
>> I prefer to avoid unnumbered links. I think it is much less confusing =
>if=20
>> source addresses of error ICMPs are always addresses from the =
>interface that
>> generated the error.
>
>these two paragraphs are mutually exclusive. you cannot require that an 
>ICMP error is sourced from the interface that generated the error and at 
>the same time require that a router use the strong host model.

Why? 

In the strong host model, every interface has a global address and some way 
of forwarding packets to a default router. 

So the interface that generates the ICMP uses it's own address as the source
of the ICMP and forwards it to a default router, which is typically the system
itself because we are talking about a router, but it could be an default
router.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Apr 2010 15:52:23 +0200

>router.  Thus, yes, there will be interoperability problems.

The SP router has a route for the entire delegated prefix, with as nexthop the
link local address of the CPE.

So I don't see how this could possibly go wrong.

Like I said, from the point of view of the SP router, assigning an address
to a virtual interface or to the WAN interface is almost indistinguishable.

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Apr 2010 07:06:28 -0700

What makes me react here is that in IPv4 networks there are in fact interfaces that have no IP addresses, and routing protocols like OSPFv2 have to specially treat them. One of the things I like about IPv6 is that it actually has an address on those links, even if it's useless for anyone not on the link. Protocols and internal functions that deal with them can be consistent.

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Apr 2010 16:55:22 +0200

Philip,

>> the same time require that a router use the strong host model.

isn't that obvious?
if you generate an ICMP message from e.g Ethernet0 destined to a destination on Serial0?
since the error happened on Ethernet0, that's the address you want to use as a source for the ICMP. you cannot do this with the strong host model.

/ot

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Apr 2010 19:24:43 +0200

>isn't that obvious?

No it isn't.

>since the error happened on Ethernet0, that's the address you want to 
>use as a source for the ICMP. you cannot do this with the strong host 
>model.

Suppose we have a packet with source S, and destination D. At Ethernet0 with
address I we discover that we cannot forward the packet anymore. So we
generate an ICMP with source I and destination S and use Ethernet0's default
router (probably internal to the node because we a talking about a router) to
send the packet on its way to S.

Whether destination D is at Serial0 or not is irrelant.

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Apr 2010 19:57:44 +0200

> Whether destination D is at Serial0 or not is irrelant.

me thinks you are confused...

/ot

---

From: Philip Homburg <[email-masked]>
Date: Wed, 07 Apr 2010 09:19:10 +0200

In your letter dated Tue, 6 Apr 2010 19:57:44 +0200 you wrote:
>> Suppose we have a packet with source S, and destination D. At >Ethernet0 with
>> generate an ICMP with source I and destination S and use Ethernet0's >default
>> router (probably internal to the node because we a talking about a >router) to

Yes, I am completely confused about the point you are trying to make.

But I have more enough experience with IPv4 and IPv6 strict multi-homing
implementations to know how they behave in practice.

So maybe you can give enough details about your scenario to make it possible
for someone else to verify whether strict multi-homing will fail in the
way you say it will or not.

---

From: Ole Troan <[email-masked]>
Date: Wed, 7 Apr 2010 10:47:58 +0200

On Apr 7, 2010, at 9:19 , Philip Homburg wrote:

>>> Suppose we have a packet with source S, and destination D. At =
>> Ethernet0 with
>>> generate an ICMP with source I and destination S and use Ethernet0's =
>> default
>>> router (probably internal to the node because we a talking about a =
>> router) to
>>> =20

what is "strict multi-homing"?

in the following figure from the draft:

                             |                             /
                             | Customer                   /
                             | Internet connection       /
                          Wi |
                      +------+--------+                  \
                      |     IPv6      |                   \
                      | Customer Edge |                    \
                      |    Router     |                    /
                      +---+-------+-+-+                   /
          Network A       |       |   Network B          | End-User
    ---+-------------+----+-    --+--+-------------+---  |network(s)
       |             |               |             |      \
   +----+-----+ +-----+----+     +----+-----+ +-----+----+  \
   |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |  /
   |          | |          |     |          | |          | /
   +----------+ +-----+----+     +----------+ +----------+/

you have a source S on the Internet sending to a destination D on Network A. D does not exist on network A. you previously said you wanted an ICMP error to use a source address giving most information about where the problem occurred, i.e the IPv6 CE router's address on the interface to network A.

the ICMP error message will be sent back to S through interface Wi.

the strong host model will require that the ICMP message is sent with an address from Wi.
the weak host model allows the use of a source address from the interface connected to network A.

/ot

---

From: Mark Smith <[email-masked]>
Date: Thu, 8 Apr 2010 00:30:42 +0930

On Tue, 6 Apr 2010 07:06:28 -0700

> What makes me react here is that in IPv4 networks there are in fact interfaces that have no IP addresses, and routing protocols like OSPFv2 have to specially treat them. One of the things I like ab…

I agree. I really liked Novell IPX's "link local" network address
because it was really easy to remember - 0x00000000.

---

From: Gert Doering <[email-masked]>
Date: Wed, 7 Apr 2010 17:36:37 +0200

Hi,

> to a virtual interface or to the WAN interface is almost indistinguishable.

Think "ND/NA/DAD" and "connected routes".  There is a lot of difference.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  150584

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: Philip Homburg <[email-masked]>
Date: Wed, 07 Apr 2010 23:15:54 +0200

>Think "ND/NA/DAD" and "connected routes".  There is a lot of difference.

DAD:
- The SP router sees a couple of multicasts for a random IPv6 address which
  it will ignore.
NS/NA:
- I said that before, in rare circumstances, the SP router may see a NS
  with that address as source address. Is that a really big deal? 

Please explain how you would get a connected route? Even though the SP
router may create a NC entry for the address, I don't why it would also
consider the address to be onlink. Unless you consider every address with a
NC entry to be onlink.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 07 Apr 2010 23:20:30 +0200

In your letter dated Wed, 7 Apr 2010 10:47:58 +0200 you wrote:
>you have a source S on the Internet sending to a destination D on =
>Network A. D does not exist on network A. you previously said you wanted =
>an ICMP error to use a source address giving most information about =
>where the problem occurred, i.e the IPv6 CE router's address on the =
>interface to network A.
>
>the strong host model will require that the ICMP message is sent with an =
>address from Wi.
>the weak host model allows the use of a source address from the =
>interface connected to network A.

No. The interface attached to network A will generate the ICMP when 
neighbor discovery fails and will use its own IP address. It will then pass
the ICMP to the default router associated with interface A. Because the node
itself is a router, it can forward the packet internally and the packet will
probably leave over Wi.

---

From: Ole Troan <[email-masked]>
Date: Thu, 8 Apr 2010 08:03:49 +0200

> itself is a router, it can forward the packet internally and the packet will

_iff_ you modeled your router as a host stack per interface with an internally routed network between the logical host stacks, you might pretend this is still the strong host model.

for the systems I know, what you describe is the weak host model.

again, can you please explain what problem you are trying to solve and how WPD-6 in the draft prohibits that?

/ot

---

From: Philip Homburg <[email-masked]>
Date: Fri, 09 Apr 2010 11:41:28 +0200

In your letter dated Thu, 8 Apr 2010 08:03:49 +0200 you wrote:
>again, can you please explain what problem you are trying to solve and =
>how WPD-6 in the draft prohibits that?

What we were discussing lately was about WAA-8 and WAA-9.

WPD-6 is minor issue. I very much prefer that a real routing protocol, such as
RIPng, is used between routers to advertise a default route.

In my opinion, Route Advertisements are getting way too overloaded: on the
host side with information that is not related to routing (and addressing)
such the DNS option.

And on the router side by advertising not just a default router for a host
(which may not have a default route to the internet) but the actual default
route itself.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 9 Apr 2010 08:50:20 -0500

> Please explain how you would get a connected route? Even though the SP
router may create a 
> NC entry for the address, I don't why it would also consider the
address to be onlink. 
> Unless you consider every address with a NC entry to be onlink. 

Considering every address with a NC entry to be onlink is, exactly, what
RFC 4861 does until
http://www.ietf.org/id/draft-ietf-6man-ipv6-subnet-model-10.txt came
along, which updates RFC 4861 (and is currently in the IESG queue).
However, I believe that, in this case, even though the SP router WILL
observe and possibly react to the NS(DAD), and may (if not updated by
subnet-model yet), create a connected route to that address, I believe
that in this particular case, the forwarding answer is the same whether
it considers the destination to be off-link or on-link - because the
destination of a forwarded packet is the same - in this particular,
quirky case (not in general).  And, the fact that the interface will now
respond to an NS with an NA (whereas it didn't before), I think will be
OK - because the behavior is a strict superset of what it had before.
So - I believe that in this particular case, where you assign an address
from the off-link pool to the interface that would otherwise get the
packet if considered off-link, will actually work. 

You got lucky this time, but in general, when you mess around with
on-link determination you usually end up with no connectivity.

- Wes