Subject: Re: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt]

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 09:56:30 +0100 (CET)

On Wed, 31 Jan 2018, Lorenzo Colitti wrote:

>> Not if the network implements SAVI.
>
> But if it does, that allows the hosts to mount a state exhaustion attack on
> the network by creating new IP addresses. Remember, one of the biggest
> advantages of the prefix-per-host model is that it has none of the
> scalability issues inherent in individually tracking IP addresses.

SAVI-style functionality can enforce prefix-per-host in a (semi) shared 
L2. That's what it does.

Remember, SAVI supports DHCPv6-PD in a shared medium as well, there is no 
either/or here.

> Sure. Now write down how it will scale without limiting the number of IP 
> addresses that each host can use.

You have drawn the wrong conclusions about what SAVI is. The "A" in SAVI 
can mean /64, /56 or whatever. It doesn't need to be on a per-address 
basis.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 10:02:04 +0100 (CET)

I can only guess what you wrote down here. So I'm going to guess that you 
wrote "You're saying hosts that have a common LL prefix *aren't* on the 
same link?" and answer that.

Your definition if "link" is too rigid. There can be lots of things done 
on L2 that would mean the answer to your question is "well, kind of".

If two hosts can't talk to each other directly over L2 (all traffic is 
forwarded via the router), the router (perhaps) defends their respective 
LLA and does forwarding between these LLA addresses, the L2 (perhaps) 
enforces LLA/MAC address mapping (using SAVI) etc, are they on the same 
link? The router sees all their traffic coming in on the same interface.

The answer is: "Well, kind of, but not really".

It's complicated.

On Thu, 1 Feb 2018, Mark Smith wrote:

> On 31 Jan 2018 20:49, "Mikael Abrahamsson" <[email-masked]> wrote:
>
> On Wed, 31 Jan 2018, Mark Smith wrote:
>
> RFC8273 fails the proper layer 2 isolation/per-host link/LAN requirement
>> too.
>>
>
> No, it doesn't. It just doesn't specify how this is to be achieved. I am of
> the opinion that it doesn't need to, and it shouldn't. Yes, someone
> implementing this should make sure that L2 assures that customers can't
> spoof each other, that source validation etc is in place, but I am of the
> opinion that RFC8273 doesn't need to specify how that should be done.
>
>
> The hosts are all sharing the same Link-Local prefix, rather than each host
>> having its own instance of the Link-Local prefix. They're all using the
>> same router interface, rather than each host having its own dedicated
>> router interface. There is sharing of IP layer resources between multiple
>> hosts, so the hosts are not on separate links.
>>
>
> Sure.
>
>
> Per RFC4291, in the Addressing Model section,
>>
>> "Currently, IPv6 continues the IPv4 model in that a subnet prefix is
>>   associated with one link."
>>
>> multiple hosts that share just one common IPv6 subnet of possibly a
>> number on the link are members of the same one link.
>>
>
> But the GUA prefix isn't the same, just the LLA.
>
>
>
> You're saying hosts that have a common LL prefix *aren't* on the same link?
>
>
>
>
> So when a host attaches to a port, the layer 2 device allocates a new
>> virtual link, dedicated to the host, and then signals the router, which
>> then allocates a new Link-Local prefix, new GUA and possibly ULA prefix,
>> and then creates a new router interface for that individual host?
>>
>
> No. Those are your requirements, it's you who are saying all of those are
> needed. Not me.
>
>
> I don't have any experience or detailed knowledge of it , however I'm
>> reminded of Access Node Control Protocol - RFC6320. Perhaps a generalised
>> version of that for other types of layer 2 edge devices might be an option.
>>
>
> PPPoE doesn't solve the mac address duplication problem, either. Only
> separate L2 per user solves that.
>
> So what I have been proposing for lots of years is to keep the 1:N model
> for IPv4 (because that's what a lot of people do), but create
> one-vlan-per-user for IPv6, using ethertype based vlans. This requires no
> host changes.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Feb 2018 19:09:48 +0900

> SAVI-style functionality can enforce prefix-per-host in a (semi) shared

Are you talking about something that's not standardized? All the SAVI RFCs
that I have seen track individual addresses.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 12:04:16 +0100 (CET)

On Thu, 1 Feb 2018, Lorenzo Colitti wrote:

> Are you talking about something that's not standardized? All the SAVI 
> RFCs that I have seen track individual addresses.

You're right, it seems work was started but never finished:

https://www.ietf.org/proceedings/77/slides/savi-1.pdf

I thought this was completed. Pity.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/15-s/ip6f-15-s-book/ip6-src-guard.html

It looks like Cisco has support for DHCPv6-PD source guard, but it looks 
like this was never standardized in the IETF (SAVI). I'm sure other 
vendors have this functionality as well, as this is an obvious requirement 
from potential customers with the need of these first-hop security 
features.

It's similar to the fact that DHCPv6 relay snooping and route installation 
for PD was never standardized, but most vendors have this functionality 
anyway.

I have several times in the past few years brought up SAVI and that we 
should take this into account when we design protocols, but I have been 
met with no interest what so ever so far. I still haven't given up hope 
that this will change, because I think it's an important functionality to 
have, even if some people think it's a protocol layer violation (which is 
one of the arguments I have been met with before).

---

From: Sander Steffann <[email-masked]>
Date: Thu, 1 Feb 2018 12:12:59 +0100

Hi,

> I thought this was completed. Pity.

https://tools.ietf.org/html/rfc7039#section-7 does mention DHCPv6-PD snooping in a different context, but indeed the full spec on the details has never made it :(

Cheers,
Sander

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Feb 2018 16:29:49 +0000

Hi,

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
> Sent: Thursday, February 01, 2018 3:04 AM
> To: Lorenzo Colitti <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt]
> 

DHCPv6 relay snooping and route installation does not need to be
standardized, as they are implementation details. As you say, most
vendors have figured out how to do it in their own implementation
specific fashions. For example, on linux "ip route add" works fine.

If we wanted something standardized, it would be Relay Agent
Assignment Notification (RAAN):

https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-agentopt-delegate/

But, efforts to get that standardized fizzled on multiple occasions simply
because there was no perceived need for it.

Thanks - Fred
 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 17:35:08 +0100 (CET)

On Thu, 1 Feb 2018, Templin, Fred L wrote:

> But, efforts to get that standardized fizzled on multiple occasions 
> simply because there was no perceived need for it.

Considering how vendors get it wrong (personal experience), I'd say I do 
not share this opinion that there is no perceived need for it.

Also, in my discussions with people it seems to me that some think that 
"snooping" is the wrong thing to do so they're opposed to this approach 
completely.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Feb 2018 16:42:36 +0000

Hi Mikael,

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Thursday, February 01, 2018 8:35 AM
> To: Templin, Fred L <[email-masked]>
> Cc: Lorenzo Colitti <[email-masked]>; 6man WG <[email-masked]>
> Subject: RE: L=0 [was draft-pioxfolks-6man-pio-exclusive-bit-02.txt]
> 

You are welcome to go breathe some new life into RAAN on the dhc list, but
I don't think you will get much support. It just isn't needed when all the relay
has to do is snoop the IA_PD's and do the appropriate route manipulations. If
you want a public domain code example, you can find it here:

http://linkupnetworks.net/aero/AERO-OpenVPN-1.0.tgz

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 18:11:20 +0100 (CET)

On Thu, 1 Feb 2018, Templin, Fred L wrote:

> has to do is snoop the IA_PD's and do the appropriate route manipulations.

It sounds so easy, yet there are so many ways vendors get it wrong. Some 
examples:

Implementor takes for granted that there will never be duplication of CIDs 
seen on different interfaces.

Implementor thinks it's a good idea to only answer single CID per 
interface.

Implementor thinks it's ok to proxy-answer questions and not even ask the 
DHCPv6 server.

Implementor thinks it's ok to not relay answers from DHCPv6 server that it 
hasn't seen a question for (or that it forgot about it).

These are just some issues (not exhaustive list) that I have had in the 
past 6 months with one multi-billion USD "leading network equipment 
vendor".

Yes, I hate DHCPv6-PD.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Feb 2018 17:27:25 +0000

> Sent: Thursday, February 01, 2018 9:11 AM

Here's you:

  "DHCPv6 PD relay route assignment is broken"

Here's me:

  [ Running code ]

> Yes, I hate DHCPv6-PD.

I am trying to understand this and failing. Is it the way the acronym sounds
as it rolls of your tongue? Is it a loathing of the many  public domain and
proprietary implementations? Do you think there is something flawed
with the protocol messaging?

I have also shown how IPv6ND and DHCPv6PD can be combined into a
unified service for all autoconfiguration needs. Even if it were to be pure
IPv6ND, though, there would still need to be a control messaging protocol
for route lifetime management that does pretty much the same thing that
DHCPv6 control messaging already does. So, why not just use DHCPv6PD?

Thanks - Fred

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 18:39:50 +0100 (CET)

On Thu, 1 Feb 2018, Templin, Fred L wrote:

> I am trying to understand this and failing. Is it the way the acronym 
> sounds as it rolls of your tongue? Is it a loathing of the many public 
> domain and proprietary implementations? Do you think there is something 
> flawed with the protocol messaging?

Yes. All of it.

Btw, around 2008-2012 when I started dibbling with IPv6 I ran into the 
same problem with DHCPv6 public domain server(s) implementation that was 
available didn't have RIB interaction. So yes, I could do PD, I just 
couldn't make it actually useful.

> I have also shown how IPv6ND and DHCPv6PD can be combined into a unified 
> service for all autoconfiguration needs. Even if it were to be pure 
> IPv6ND, though, there would still need to be a control messaging 
> protocol for route lifetime management that does pretty much the same 
> thing that DHCPv6 control messaging already does. So, why not just use 
> DHCPv6PD?

Because it was designed as ships in the night with routers. Because it 
generally doesn't support telling the device that "oops, your lease is up 
before its time".

If we just gave up the idea that the DHCPv6 server lives anywhere else 
than on a router (with all consequences that has), that would solve some 
parts of my issues with it. Specifying what some events on ND would 
reflect on DHCPv6 resources (operational document) would also help.

So your proposal of tunneling DHCPv6 inside RS/RA and if that means we get 
operational guidance such as "zero lifetime in the RA means deprecate all 
DHCPv6 resources you have" and similar, would help a long way.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Feb 2018 17:49:06 +0000

Hi Mikael,

> Sent: Thursday, February 01, 2018 9:40 AM

I get your frustration, but I believe DHCPv6PD works if the implementer
simply follows the specs. Today, the specs are [RFC3315] and [RFC3633],
but the two are currently being rolled into a single spec as [rfc3315bis].
The (bis) is currently in late stages of publication, so if we think there is
something wrong now is the time to comment.

> DHCPv6 resources you have" and similar, would help a long way.

Do we want to put some energy behind this?

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Thu, 1 Feb 2018 19:22:37 +0100

> If we just gave up the idea that the DHCPv6 server lives anywhere else than on a router (with all consequences that has), that would solve some parts of my issues with it.

DHCPv6 PD has never been specified for any other model.
What this has to do with PIO-X I have no idea.

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Feb 2018 07:57:31 +1300

> same link?" and answer that.

I must confess that this question caused me to stop reading. Afaik all LL prefixes
are identical, namely fe80::/64. So, they are useless for determining whether
host are on the same link.

Since this thread is no longer about either L=0 or PIO-X could somebody please
change the subject to describe what it actually is about?

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 1 Feb 2018 20:06:36 +0100 (CET)

On Thu, 1 Feb 2018, Templin, Fred L wrote:

> simply follows the specs.

Didn't we just agree that DHCPv6-PD and relays was blatantly obvious and 
didn't need spec:s?

> Do we want to put some energy behind this?

I'd prefer if we took some of DHCPv6 option space, some of the state 
machines, and ditched the rest, and explained how this was done using 
something else, for instance ND.

But short of that yes, there should be operational documents (in v6ops 
perhaps) that tells implementors how SLAAC and DHCPv6 works together, and 
what certain SLAAC messages means for DHCPv6 based resources.

---

From: Mark Smith <[email-masked]>
Date: Sun, 4 Feb 2018 10:06:52 +1100

> on L2 that would mean the answer to your question is "well, kind of".

It  doesn't matter what my definition is, what matters is what IPv6's
definition is.

IPv6 expects a link supports multicast, so that RAs, ND and DAD work. If
the link doesn't support multicast, it is to be emulated per IPv6 over NBMA.

IPv6 expects any to any unicast, because the Link Local Prefix is marked as
On-link, and that cannot be changed.

IPv6 expects Link-Locals to work for applications when GUAs/ULAs won't,
because IPv6 src/dest selection prefers LLAs over GUA/ULA when given a
choice.

(A perverse situation is that src/dst address selection prefers LLAs over
GUA/ULAs, yet on these types of links, as LLA L=1 (and cannot be changed),
and GUA/ULA is set to L=0 via RA PIO, application connectivity will fail
even though hosts on the link are reachable via the GUA/ULA addresses.
Preferring LLAs makes sense, smaller scope and more local addresses should
be more reliable than greater and less local addresses.)

> forwarded via the router),

the router (perhaps) defends their respective LLA and does forwarding
> between these LLA addresses, the L2 (perhaps) enforces LLA/MAC address
> mapping (using SAVI) etc, are they on the same link? The router sees all
> their traffic coming in on the same interface.
>

I think having a device pretend to be another is a hack. The better
solution would be to indicate to hosts that they are to reach LLAs via the
router(s) on the link - "Indicating Link-Local Unicast Destinations are
Off-Link"  -
https://www.ietf.org/archive/id/draft-smith-6man-link-locals-off-link-00.txt

Then you still have the multicast reachability issue, meaning that ND and
DAD don't work.

The answer would appear to be DAD Proxy (RFC6957). Trouble is, that is also
a hack because it is one device pretending to be another. DAD Proxy doesn't
specify how two routers on the link for redundancy are to work either.
(There's some discussion of this multicast issue in the draft towards the
end of the "IPv6 over CBMA Links" section.)

When you're down a complexity, hacks and work arounds rat hole like this, I
think it is worth stepping back and asking "what problem are you trying to
solve"?

So what is all this hackery trying to achieve? To overcome link layer
constraints imposed by the same people who chose put them there in the
first place?!

Why are people trying to put multiple entirely untrusted hosts within the
same IPv6 subnet/on the same link that assumes implicit host trust?

Why are people, in one part of the network, likely using subnets/virtual
links to group together trusted hosts, meaning they're using network layer
subnets to create trusted host security domains to implement security
policy, yet in another part of the network, choose to group together
entirely untrusted hosts in the same subnet/link?!

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 4 Feb 2018 04:49:11 +0100 (CET)

> same IPv6 subnet/on the same link that assumes implicit host trust?

.... and here's why some things are never standardized in the IETF yet 
it's still in use by millions of subscribers. Vendors produce 
functionality that people put in their RFPs, not what people showing up in 
the IETF thinks makes sense to them.

I could give you the reasons why some people do this, but I imagine you'd 
just reject them as being "wrong". And from a puritan point of view, you'd 
probably be correct.

---

From: Mark Smith <[email-masked]>
Date: Mon, 5 Feb 2018 07:41:27 +1100

On 4 February 2018 at 14:49, Mikael Abrahamsson <[email-masked]> wrote:

> it's still in use by millions of subscribers. Vendors produce functionality
> that people put in their RFPs, not what people showing up in the IETF
> thinks makes sense to them.
>

What a useless email.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Feb 2018 21:11:13 +0100

Le 01/02/2018 à 18:39, Mikael Abrahamsson a écrit :
[...]
> than on a router (with all consequences that has), 

FWIW in my lab the DHCPv6 server has always run on a Host, i.e. a 
one-interface computer.  And there are multiple relays.

Alex

that would solve some
> So your proposal of tunneling DHCPv6 inside RS/RA and if that means we 
> get operational guidance such as "zero lifetime in the RA means 
> deprecate all DHCPv6 resources you have" and similar, would help a long 
> way.
>