Subject: [v6ops] draft-ietf-v6ops-host-addr-availability

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 10 Dec 2015 17:47:27 +0000

We have an updated version of draft-ietf-v6ops-host-addr-availability. I'd like to believe that it addresses the discussion at IETF 94 and subsequent mail discussion. Does it?

We had a WGLC September 24-October 7, an update, the latest discussion, and this update. I believe that we are done. Barring objections, we'll send it in.

https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-03.txt

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Dec 2015 17:59:27 +0000

Hi Fred,

I have made two points: 1) that DAD implications should be discussed, and
2) that strong vs weak end system alternatives should be discussed. The
new draft addresses point 1) to a certain extent (again, this was my point)
but does not fully address point 2) as the past messages on the list have
shown.  So, IMHO the draft is not yet ready to be advanced.

Thanks – Fred
[email-masked]

From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Thursday, December 10, 2015 9:47 AM
To: [email-masked]
Subject: [v6ops] draft-ietf-v6ops-host-addr-availability

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 10 Dec 2015 20:00:25 +0000

Hmm. What specifically would you like it to say?

What I am thinking about is a similar discussion in https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-02#section-1.1. The context there was that said draft wants a host to send its packets to a predictable first hop router unless it has direct connectivity to the destination, and that first hop router is a/the one that emitted a relevant RA. That's not quite RFC 1122's "strong host" model, but it is definitely not the "weak host" model. The host model is relevant because which router it talks with is important.

In draft-ietf-v6ops-host-addr-availability, why is the host model important? I understand it to be saying that where a host might be given one address, it should be possible to give the host multiple addresses, and throws some numbers around. In that context, is the strong or weak host model, or the model in draft-ietf-6man-multi-homed-host important?

From: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 10, 2015 at 9:59 AM
To: Fred Baker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-ietf-v6ops-host-addr-availability

Hi Fred,

Thanks – Fred
[email-masked]<mailto:[email-masked]>

From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Thursday, December 10, 2015 9:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [v6ops] draft-ietf-v6ops-host-addr-availability

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Dec 2015 20:48:09 +0000

Hi Fred,

Here is a suggestion:

---
OLD:
Also, a DHCPv6 PD model with a dedicated /64 per host makes it
possible for the host not to assign global IPv6 addresses directly to
its physical network interface, but instead to assign them to an
internal interface such as a loopback interface.  This obviates the
need to perform Neighbour Discovery and Duplicate Address Detection
for anything other than the link-local address on its physical
network interface, reducing network traffic.

NEW:
Also, a DHCPv6 PD model with a dedicated /64 per host makes it
possible for the host to assign global IPv6 addresses without the need
to perform Neighbour Discovery and Duplicate Address Detection
for anything other than the link-local address on its physical network
interface, reducing network traffic. The host can assign the addresses
either to an internal interface such as a loopback interface per the
weak end system model, or to the physical interface per the strong
end system model as long as it does not add the /64 to the physical
interface’s Prefix List.
---

In terms of why this is important, I would defer to RFC1122 and to what
is expected of currently widely-deployed implementations. AFACIT,
strong end system is more “host-like” than weak end system. How
important that is is beyond the scope of my understanding, but an
alternative that can and should be mentioned in this document.

Thanks – Fred

From: Fred Baker (fred) [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 12:00 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: draft-ietf-v6ops-host-addr-availability

Hi Fred,

Thanks – Fred

---

From: Mark Smith <[email-masked]>
Date: Fri, 11 Dec 2015 08:27:55 +1100

Sorry to be terse, I'm on a train about to get off.

I think there needs to be some discussion around MLD in the context of
delegating a prefix via PD. I think the host needs to act as a host in that
regard, so MLD joins will need to be sent for Solicited-Node MC groups for
"loopback" local addresses even if dad isn't needed.
On 11 Dec 2015 7:48 AM, "Templin, Fred L" <[email-masked]> wrote:

> *From:* Fred Baker (fred) [mailto:[email-masked]]
> *Sent:* Thursday, December 10, 2015 12:00 PM
> *To:* Templin, Fred L
> *Cc:* [email-masked]
> *Subject:* Re: draft-ietf-v6ops-host-addr-availability
>
>
>
> What I am thinking about is a similar discussion in
> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-02#section-1.1.
> The context there was that said draft wants a host to send its packets to a
> predictable first hop router unless it has direct connectivity to the
> destination, and that first hop router is a/the one that emitted a relevant
> RA. That's not quite RFC 1122's "strong host" model, but it is definitely
> not the "weak host" model. The host model is relevant because which router
> it talks with is important.
>
>
>
> In draft-ietf-v6ops-host-addr-availability, why is the host model
> important? I understand it to be saying that where a host might be given
> one address, it should be possible to give the host multiple addresses, and
> throws some numbers around. In that context, is the strong or weak host
> model, or the model in draft-ietf-6man-multi-homed-host important?
>
>
>
> *From: *"Templin, Fred L" <[email-masked]>
> *Date: *Thursday, December 10, 2015 at 9:59 AM
> *To: *Fred Baker <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: draft-ietf-v6ops-host-addr-availability
>
>
>
> Hi Fred,
>
>
>
> *From:* v6ops [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Fred Baker (fred)
> *Sent:* Thursday, December 10, 2015 9:47 AM
> *To:* [email-masked]
> *Subject:* [v6ops] draft-ietf-v6ops-host-addr-availability
>
>
>
> We have an updated version of draft-ietf-v6ops-host-addr-availability. I'd
> like to believe that it addresses the discussion at IETF 94 and subsequent
> mail discussion. Does it?
>
>
>
> We had a WGLC September 24-October 7, an update, the latest discussion,
> and this update. I believe that we are done. Barring objections, we'll send
> it in.
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 10 Dec 2015 22:01:20 +0000

Hi Mark,

I think MLD only applies to the case of assigning addresses to the physical interface,
and not the case of assigning addresses to a loopback interface – in the loopback
case, the addresses are clearly not on-link on the physical interface and so should
require neither DAD nor MLD over the physical interface.

In the case of assigning the addresses to the physical interface, MLD for each
solicited node multicast address can be avoided for the same reason that DAD
can be avoided – the addresses are not really “on-link” on the physical interface
even though they are assigned to the physical interface. The node therefore
looks like a router to the outside world but acts as a host internally. But yes, it
probably makes sense to mention MLD in some capacity.

Thanks – Fred

From: Mark Smith [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 1:28 PM
To: Templin, Fred L
Cc: Fred Baker (fred); v6ops list
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability

I think there needs to be some discussion around MLD in the context of delegating a prefix via PD. I think the host needs to act as a host in that regard, so MLD joins will need to be sent for Solicited-Node MC groups for "loopback" local addresses even if dad isn't needed.
On 11 Dec 2015 7:48 AM, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Fred,

Here is a suggestion:

---
OLD:

NEW:

Thanks – Fred

From: Fred Baker (fred) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 10, 2015 12:00 PM
To: Templin, Fred L
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: draft-ietf-v6ops-host-addr-availability

Hi Fred,

Thanks – Fred

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Smith <[email-masked]>
Date: Fri, 11 Dec 2015 13:41:00 +1100

Hi Fred,

> require neither DAD nor MLD over the physical interface.

Yes, thinking though it more, you're right about MLD for Solicited Node
groups for the internal addresses not being necessary in this scenario.

> probably makes sense to mention MLD in some capacity.

I agree.

Under normal circumstances, I think the MLD messages for the applications
that are using addresses from within the delegated /64 would be sent over
the same link, which would be the internal link, and therefore pointless.

So I think in this scenario, they instead need to be sent over the link the
prefix was received over via DHCPv6-PD.

Regards,
Mark.

>>
>>
>>
>> From: "Templin, Fred L" <[email-masked]>
>> To: Fred Baker <[email-masked]>, "[email-masked]" <[email-masked]>
>> We have an updated version of draft-ietf-v6ops-host-addr-availability.
I'd like to believe that it addresses the discussion at IETF 94 and
subsequent mail discussion. Does it?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 11 Dec 2015 13:35:45 +0900

Fred,

I think your suggested text:

> end system model as long as it does not add the /64 to the physical

is a clear violation of this text in RFC 4862:

   To ensure that all configured addresses are likely to be unique on a
   given link, nodes run a "duplicate address detection" algorithm on
   addresses before assigning them to an interface.  The Duplicate
   Address Detection algorithm is performed on all addresses

IIUC you're saying that if the host assigns addresses to the interface but
doesn't add the /64 to the prefix list, then it can skip DAD. Can you point
to normative text in RFC 4862 that backs up your position? We can't add
text to this document that violates RFC 4862.

Cheers,
Lorenzo

---

From: David Farmer <[email-masked]>
Date: Fri, 11 Dec 2015 02:01:16 -0600

Lorenzo,

I think you hit the nail on the head; you make it clear that hosts still 
need to be good neighbors even if, and especially if, the network 
doesn't enforce a limit.

On a side note, we're beginning a WiFi infrastructure procurement cycle 
here at the University of Minnesota.  I'll be adding /64 prefix per host 
as feature I'm looking for in our RFP.

Fred,

The update seems to cover my issue, I think it's good to go.

Thanks

On 12/10/15 11:47 , Fred Baker (fred) wrote:
> and this update. I believe that we are done. Barring objections, we'll
> send it in.
>

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 11 Dec 2015 12:03:56 +0100

Le 10/12/2015 21:48, Templin, Fred L a écrit :
> possible for the host not to assign global IPv6 addresses directly
> to its physical network interface, but instead to assign them to an

The "instead" word in this OLD paragraph makes read as if the only means 
to avoid DAD and NA on the egress interface is to assign the global on 
an internal interface ("virtual", or "logical" interface, see a 
definition of it in draft-ietf-netext-logical-interface-support).

That's not the only means.

To stress the point: you can also assign it on the real egress 
interface, provided you dont put the prefix as an on-link prefix, and 
maybe set variable=0.

> network

I agree.

Alex

> *From:*Fred Baker (fred) [mailto:[email-masked]] *Sent:* Thursday,
> December 10, 2015 12:00 PM *To:* Templin, Fred L *Cc:*
> [email-masked] *Subject:* Re:
> draft-ietf-v6ops-host-addr-availability
>
>  The context there was that said draft wants a host to send its
> packets to a predictable first hop router unless it has direct
> connectivity to the destination, and that first hop router is a/the
> one that emitted a relevant RA. That's not quite RFC 1122's "strong
> host" model, but it is definitely not the "weak host" model. The host
> model is relevant because which router it talks with is important.
>
> important? I understand it to be saying that where a host might be
> given one address, it should be possible to give the host multiple
> addresses, and throws some numbers around. In that context, is the
> strong or weak host model, or the model in
> draft-ietf-6man-multi-homed-host important?
>
> *From: *"Templin, Fred L" <[email-masked]
> <mailto:[email-masked]>> *Date: *Thursday, December 10,
> 2015 at 9:59 AM *To: *Fred Baker <[email-masked]
> <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>> *Subject: *RE:
> draft-ietf-v6ops-host-addr-availability
>
> Hi Fred,
>
> [email-masked] <mailto:[email-masked]>
>
> *From:*v6ops [mailto:[email-masked]] *On Behalf Of *Fred
> Baker (fred) *Sent:* Thursday, December 10, 2015 9:47 AM *To:*
> [email-masked] <mailto:[email-masked]> *Subject:* [v6ops]
> draft-ietf-v6ops-host-addr-availability
>
> We have an updated version of
> draft-ietf-v6ops-host-addr-availability. I'd like to believe that it
> addresses the discussion at IETF 94 and subsequent mail discussion.
> Does it?
>
> We had a WGLC September 24-October 7, an update, the latest
> discussion, and this update. I believe that we are done. Barring
> objections, we'll send it in.
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 11 Dec 2015 12:05:00 +0100

Thanks for the new draft.

I agree with its main parts.

The point raised about PD is actually an excellent and new undocumented 
point for end-systems relying PD to get more addresses and, 
incidentally, avoid DAD for one address.  It's strange people block on 
it just because of DAD and a zeroed variable.

PD can only outperform SLAAC/DHCP-Adddress/64share in getting more 
addresses and avoid SLAAC on the egress interface.

Now - is your intention to avoid avoiding SLAAC on the egress interface? 
  Why?

Alex

---

From: Philip Homburg <[email-masked]>
Date: Fri, 11 Dec 2015 14:52:50 +0100

>    2) that strong vs weak end system alternatives should be discussed.

It seems to me that the only sensible model for PD is that any node
receiving a prefix is a router.

Any other interpretation just leads to confusion.

As discussed earlier, for redirection to work, the receiving node has to 
be a router for the purposes for ND.

If we declare the node to be a router then the whole strong vs weak end system
discussion goes away. 

I don't think there is any downside. In my opinion, hosts should not assign
addresses to internal interfaces and then use them on other interfaces.
If a router does that then the situation is completely clear. Being a router
doesn't seem to impose unreasonable requirements.

There is one thing that worries me. PD makes sense if the nodes receiving
prefixes are partipating in a routing protocol. But we are not doing
that (at least not in the context of this draft). Instead we have a model
where DHCPv6 essentially installs a static route in the delegating router's
RIB. In the long run this is likely to lead to all kinds of scalability 
problems.

But maybe it is best to wait for things to go wrong because the obvious
fix would involve changing ND. And I'm sure nobody would want to do that
at this time.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Dec 2015 18:55:43 +0000

Hi Philip,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Friday, December 11, 2015 5:50 AM
> To: [email-masked]
> Cc: Templin, Fred L; Fred Baker (fred)

I think we agreed before that the node must present the outward appearance
of a router, yes. But, internally, applications are presented with the appearance
of an ordinary host.

> Any other interpretation just leads to confusion.

Perhaps not if the distinction between external vs internal appearances
is specified.

>From an external appearance, yes.

>From an internal appearance, maybe not. If the interface over which the
delegated prefix is received is the same interface to which addresses from
the delegated prefix are assigned, then to applications it looks just like an
ordinary host. The AERO interface does just that, and we are now exploring
whether the same would apply to other interface types.

> doesn't seem to impose unreasonable requirements.

This is strong/weak ES consideration, where you seem to be implying that
strong ES is more "host-like". But, we are wondering if this makes a
difference to applications - will some applications prefer to run on
one ES model vs. the other?

> RIB. In the long run this is likely to lead to all kinds of scalability

It depends on how many nodes each delegating router serves. I don't
think scaling on the order of thousands would be unreasonable.
Millions might be a bit more challenging. But, if you find yourself
running up against scaling limitations in delegating routers, just add
more delegating routers.

> fix would involve changing ND. And I'm sure nobody would want to do that

I don't see any problems at this time. Well OK; there is one problem. Routers
are not supposed to send Redirects to other routers. Which means that, with
standard ND, the PD hosts would always use the dogleg path through their
default router to talk to other nodes on the link. AERO fixes this by allowing
router-to-router redirects. This is already specified in RFC6706 but updated
by AERO(bis).

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Sat, 12 Dec 2015 09:31:36 +1100

>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability

<snip>

> one ES model vs. the other?

In the context of IPv6, for a long time I wasn't sure if it followed
either the strong or weak ES model.

I thought I'd found an answer in the addressing arch RFC (RFC4291):

"2.1.  Addressing Model

   IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node."

which I think matches the definition of the weak ES model as described
in RFC1122.

I think the default address selection RFC (RFC6724) also implies weak
ES model, as it doesn't require source addresses to be selected from
the interface used to reach the destination (although it does have a
preference for them in Rule 5)

I'd also wonder if RFC1122 really applies to IPv6 hosts. Although its
title is generic ("Requirements for Internet Hosts -- Communication
Layers"), which could be explained by it being published in 1989, the
topics that might be specifically relevant to IPv6 (e.g., host models)
are specifically about IPv4 behaviours.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 12 Dec 2015 09:50:47 +1100

> receiving a prefix is a router.

I'd agree with that. I find it far easier to think about the related
issues by imagining the delegated prefix is assigned to an internal
logical interface, applications would be bound to/prefer/use addresses
present on this internal logical interface, and that these application
packets are being forwarded between the internal logical and external
physical interface. Forwarding packets between interfaces is a router
function so these are routers.

These types of "hosts" could probably be better described as stub
routers whose purpose is to run applications rather than to forward
packets (a specific name for routers used only to run applications
would be very useful). I think the gaps come about because these
"routers" are not full participants in the routing domain protocols.

Static routing for unicast traffic takes care of the unicast problem,
but as they're not going to be running multicast routing protocols,
and there is no effective automated static routing configuration
protocol for multicast (as DHCPv6-PD is for static routing unicast
towards the host), it is necessary to use the normal host to router
multicast protocol instead (MLD), but to run it on a different
interface than normal - on the upstream physical interface, and only
for non-Solicited Node multicast groups (as they would only be useful
appearing on the internal interface where the addresses are, if
they're actually necessary.)

> RIB. In the long run this is likely to lead to all kinds of scalability

I'm not sure it would lead to scalability problems. RIB entries are
being traded for neighbor cache entries and possibly solicited node
multicast group entries if they were being tracked, so there would
probably be a nett benefit if the RIB, neighbor cache and multicast
group tracking resources are shared in the router.

> fix would involve changing ND. And I'm sure nobody would want to do that

Agree.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Dec 2015 22:58:51 +0000

Hi Mark,

> From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
> Sent: Friday, December 11, 2015 2:51 PM
> To: Philip Homburg
> Cc: v6ops list

Right, but that is not the case when the internal logical interface and
outgoing interface are one and the same, such as with the AERO
interface.  In that case, there is no internal forwarding between
multiple interfaces so, to hosted applications, it looks like an
ordinary host and not a router.

Thanks - Fred

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 11 Dec 2015 23:25:56 +0000

>are specifically about IPv4 behaviours.

Again speaking as an individual contributor. I was there as RFC 1122/3 came out and was present for some of the discussions, and edited RFC 1812.

The process that resulted in RFCs 1122/1123 and 1812, were they to occur today, probably would have been done in a different way. The issue was that, having tested RFCs 760 and 791, 792, and 793, developed a concept that wasn't present in classical addressing (subnets), gone through the experience with BSD 4.1 (which had a truly awful TCP implementation), CSNET (which was based on X.25, opening up a new circuit any time that the active set seemed overwhelmed, and as a result introduced reordering of IP traffic in a huge way), and the congestive collapse of the 56 KBPS NSFNet, and now facing the deployment of regional  consortia (which a few years later became commercial providers), the graybeards of the Internet felt that there was a need to capture, somehow, what the community had learned. Today, we would have a 791bis, 792bis, 793bis, perhaps a 950bis, and so on. In 1989, they were done as a single document for Host Requirements, which when published as an RFC was divided into two, and the Router Requirements as what became RFCs 1716 and 1009, updated (CIDR, primarily, but also deprecating RIP) to become 1812.

As you say, that learning was primarily about IPv4 and its companion protocols. However, I think IPv6 derives from the same roots, and we have a lot to learn from the experience in IPv4. So I would not say "RFC 1122/1123/1812 is normative for IPv6"; as a matter of fact, the title of RFC 1812 is "Requirements for IP Version 4 Routers" exactly to clarify that question, as compared to the title of its predecessor, "Towards Requirements for IP Routers". I would, however, strongly encourage consideration of the points covered in those documents by analogy.

---

From: Mark Smith <[email-masked]>
Date: Sat, 12 Dec 2015 12:00:26 +1100

Hi Fred,

> As you say, that learning was primarily about IPv4 and its companion protocols. However, I think IPv6 derives from the same roots, and we have a lot to learn from the experience in IPv4. So I would…

I suppose my thought was really just about being cautious of ascribing
RFC1122 IPv4 behaviours directly to IPv6 when there might be IPv6
specific behaviours in those areas described in IPv6 RFCs.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Sat, 12 Dec 2015 13:24:42 -0800

> of a router, yes. But, internally, applications are presented with the appearance

FWIW, that's also true inside an ordinary router too. They too have
applications that need to treat the node as a host.

A router is a superset of a host. There should never be anything a host
can do that a router cannot. (that is often overlooked in RFCs).

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Dec 2015 11:36:37 +1300

> can do that a router cannot. (that is often overlooked in RFCs).

RFC 2460 and draft-6man-rfc2460bis are explicit about this:

"2.  Terminology

   node        - a device that implements IPv6.

   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.  [See Note below].

   host        - any node that is not a router.  [See Note below].

...

   Note: it is possible, though unusual, for a device with multiple
   interfaces to be configured to forward non-self-destined packets
   arriving from some set (fewer than all) of its interfaces, and to
   discard non-self-destined packets arriving from its other interfaces.
   Such a device must obey the protocol requirements for routers when
   receiving packets from, and interacting with neighbors over, the
   former (forwarding) interfaces.  It must obey the protocol
   requirements for hosts when receiving packets from, and interacting
   with neighbors over, the latter (non-forwarding) interfaces."

     Brian

---

From: Joe Touch <[email-masked]>
Date: Sat, 12 Dec 2015 14:57:52 -0800

>    host        - any node that is not a router.  [See Note below].

And the need for the Note explains why the definition should have been, IMO:

host: a source or sink of packets to/from its IP addresses

router: a host that ALSO forwards packets that are not addressed to itself

That would have alleviated the need for the note and helped us avoid a
lot of problems that have happened since, IMO.

Joe

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Dec 2015 16:26:31 +0100

(I changed the subject to reflect that this is about DHCPv6 PD)

>of a router, yes. But, internally, applications are presented with the appe=
>arance
>of an ordinary host.

It seems to me that we (the IETF) should mostly focus on outward appearance.
In general, we do not defined host interfaces, just concepts.

There are a few exceptions, but for example the socket interface was never
extended to support happy eyeballs. And there is a lot of networking 
related APIs that are defined outside the IETF.

Of course, we should also avoid specifying behavior that is incompatible with
the socket API.

>> If we declare the node to be a router then the whole strong vs weak end s=
>ystem
>> discussion goes away.
>

By and large, the socket API doesn't really deal with interfaces. Most 
applications written using the socket API don't deal with interfaces
at all.

So from an internal appearance, where an address is assigned is mostly
irrelevant. Though of course externally visible behavior will be visible
to the application as well.

For example, in an (overly) strong ES model, if you assign an address to the
loopback interface, packets with that address as the source address
will never leave the host.

To me, the externally visible difference between strong and weak ES, is that
in strong ES, a packet will always depart from the interface to which the
address is assigned. So if a host is found to originate packets with 
source address that do not belong to the local subnet, then the host likely
uses the weak ES model (or is broken in some way).

>one ES model vs. the other?

In the past I did write a stack that had strong ES built in even when the
node was a router. That's just not recommended.

Though for a multi-homed host (that is not a router) I certainly prefer
the strong ES model. 

So for me, saying that a node that receives a prefix using PD has to behave
like a router, essentially implies weak ES. And of course that will be
visible to applications.

Though as I said before, applications written using the socket API are
generally not aware that there are different interfaces.

>I don't see any problems at this time. Well OK; there is one problem. Route=
>rs

That's certainly one interesting case. 

I was thinking about a more serious problem. Assume two routers
connected to a single link. A node on that link requests a prefix using 
DHCPv6 PD. Both routers run a DHCPv6 relay.

Absent additional specifications, only one router will install a static
route. Obviously, if the router reboots it has to restore all static
routes. Normally, a DHCP relays doesn't maintain state, so that's new.

Now, what happens if the router that has the static route goes down?
How does the other router take over?

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 15 Dec 2015 22:16:09 +0000

Hi Philip,

> Sent: Tuesday, December 15, 2015 7:27 AM
> To: [email-masked]; Templin, Fred L
> Cc: Fred Baker (fred)
> Subject: DHCPv6 PD for hosts (was: draft-ietf-v6ops-host-addr-availability)
> 

RFC4861 talks about host interfaces, and several varieties of IPv6-over-(foo)
documents also talk about host interfaces.

> applications written using the socket API don't deal with interfaces

A counter-example would be pinging a link-local address.

> like a router, essentially implies weak ES. And of course that will be

The host can display strong ES characteristics if it assigns addresses to
the interface over which the prefix delegation is received. This works
if the link over which the PD is received is link-local-only and DAD is
disabled. This is exactly the case for AERO interfaces, and may apply
to other interface types such as NBMA in general.

> How does the other router take over?

Nodes that received prefix delegations from the router will notice that
it has crashed and will request a prefix delegation from another router.
If they receive the same prefix as they were using from the first router,
then there is no need for renumbering.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Dec 2015 15:25:44 +0100

>RFC4861 talks about host interfaces, and several varieties of IPv6-over-(fo=
>o)

As far as I can tell, RFC 4861 doesn't provide any kind of API. It
describes how behavior can be described in terms of interfaces. 
It doesn't say anything about how that view should be presented to
applications.

>A counter-example would be pinging a link-local address.

Which is a problem.

As far as I know, we have no API (defined in an RFC) that allows you to
get all IPv6 for an interface. Or the other way around, given a public
IPv6 assigned to one of the interfaces of a node, to which specific 
interface it belongs.

So the net effect is that writing portable software that deals with 
link-local addresses is almost impossible because there is no way for an
application to make sense of interfaces.

>to other interface types such as NBMA in general.

Yes, but for example on wifi links, there is no reason to assume that DAD
would be disabled. And beyond that, that would create quite a bit of 
application complexity to assign multiple addresses to one interface and
make sure that the right application uses the right address.

A model where the 'host' routes between different interfaces is much
clearer for me.

But by and large I find externally visible effects more interesting.

>then there is no need for renumbering.

I'm not aware of any RFC that says that if you receive something through
a DHCP relay, you have to keep polling the relay and restart DHCP when the
relay goes away.

Is that documented somewhere?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 16 Dec 2015 19:01:48 +0000

Hi Philip,

> Sent: Wednesday, December 16, 2015 6:26 AM
> To: [email-masked]
> Subject: Re: DHCPv6 PD for hosts (was: draft-ietf-v6ops-host-addr-availability)
> 

I thought that was what we were after, i.e., being able to assign lots
of addresses to one interface. Is that not what we are after?

> A model where the 'host' routes between different interfaces is much

Yes, assigning addresses to the loopback interface the host would indeed
route between different interfaces, as would be the case for weak end
system. But, at least for AERO, it does not need to be that way and
strong end system is possible.

Plus, what does routing between interfaces mean to functions such as
MTU discovery? The application sees the MTU of the outgoing interface
when TCP sets its MSS. So, what MTU would you set on the loopback
interface to both avoid setting a too-large initial MSS and yet take
advantage of any larger MTUs afforded by the native interface?

> Is that documented somewhere?

It is in AERO. In AERO, the node can associate with multiple delegating routers
and, if one goes away, simply switch to another delegating router. Or, if all go
away, find a new delegating router and associate with it.

The node will get the same DHCPv6 PD whichever delegating router it
associates with. The routing system keeps track of which delegating
router(s) each node is currently associated with.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Thu, 17 Dec 2015 13:45:48 +0100

Hi Fred,

>of addresses to one interface. Is that not what we are after?

I assumed it was 'being able to assign lots of addresses' (actually, enough
address that don't have to resort to tricks like NAT).

For a 'desk area network' it make sense to assign a /64 to that network.
If you have lots of VMs or containers with micro services (to be fully
buzzword compliant here) you may want to have a more complicated structure,
with (virtual) LANs that connect related services and then route between
that and the rest of the internet.

>strong end system is possible.

I see assigning all address to the upstream interface more as a possibility
than as a goal. If a host receives enough /64s then the host can decide how
to best organise itself (I do note that a /64 or more per host may cause
address policy issues, but that's a separate discussion)

>advantage of any larger MTUs afforded by the native interface?

The hack to use MSS for path MTU discovery is something that is
unfortunately required until we are actually going to do path MTU blackhole 
discovery. I hope that one day we can get rid of that business, we have the
RFC, it just needs to be implemented.

That said, if you are going to play games with MSS, then setting the MTU
on the loopback device should be no problem. Various operating systems
support the creation of multiple loopback devices or other virtual devices.
So there is no reason to not have your cake and eat it too.

>It is in AERO. In AERO, the node can associate with multiple delegating rou=
>ters
>and, if one goes away, simply switch to another delegating router. Or, if a=
>ll go

I was not worried about getting the same prefix, but about the requirement
to refresh a DHCP lease when a router goes down.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Dec 2015 18:40:33 +0000

Hi Philip,

> Sent: Thursday, December 17, 2015 4:46 AM
> To: [email-masked]
> Cc: Templin, Fred L

Right, the addresses could be assigned to internal interfaces like loopbacks,
to internal virtual machines, etc. And, there may be many assigned to the
same interface, as permitted by the RFCs. How apps might use multiple
addresses assigned to the same interface is beyond the scope of this work.

> address policy issues, but that's a separate discussion)

But, a possibility that may prove useful in the future.

> to refresh a DHCP lease when a router goes down.

Routers are critical infrastructure. They should not go down very often
or, if they do, they will probably go down "hard" and come back up at
some later time. Routers that (repeatedly) go down for a few seconds
then come back up could cause oscillations in the routing system, but
this is no different than for any type of routing system.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Sat, 19 Dec 2015 14:46:37 +0100

Hi Fred,

>this is no different than for any type of routing system.

That's why my example started out with 2 routers connected to the
same link both being a DHCPv6 relay. I left out the any implication
that they would be running VRRP or something. But v6 provides enough
for rapid failover even with that.

So, bringing one router down should not have much operational impact.

With PD for hosts we get a new situation where routers have to store
and share persistent state wrt prefix leases.

---

From: Mark Smith <[email-masked]>
Date: Sun, 20 Dec 2015 09:48:13 +1100

> and share persistent state wrt prefix leases.

I think DHCPv6-PD is serving the same or similar function as routing
protocols in this scenario, so I think that means that the DHCPv6-PD client
needs to track the presence of its DHCP "neighbor" using the standard sorts
of neighbor presence discovery methods e.g. link state, neighbor
advertisements or probing.

For example, if NUD determines that the current PD router has gone away, a
DHCPv6 REBIND is triggered to see if some other available DHCP server will
provide/facilitate the delegated prefix.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 20 Dec 2015 12:03:14 +0100

>provide/facilitate the delegated prefix.

I see some problems with this approach.

The first is that ND is usually in the kernel and the DHCP client is an
application process. So the kernel would have to signal the DHCP client process
that the DHCP server is down (or the DHCP client would have to poll). Not nice.

Worse, NUD only comes into play when the host tries to send something to
its DHCP server. And there are many scenarios where that doesn't happen.

So the host would have to ping its DHCP every couple of seconds. Not good
for scalability. Also not good for battery usage.

Then when the network is interrupted for a short while, all hosts will
try to REBIND. But worse, because they know that the DHCP server they last
used is down, they would have to multicast the request. I'd like to see the
effect of that on a large wifi network.

(I have some ideas of how to solve the problem by adding stuff to ND, but
that is something for 6man).

---

From: Mark Smith <[email-masked]>
Date: Sun, 20 Dec 2015 23:13:23 +1100

> I see some problems with this approach.

Note the "for example". It may not be the best way to solve the problem,
but it is an example of how it could be solved.

Another way a host could verify that the router it received the prefix from
still has current prefix information is that the host is still receiving
traffic to the prefix via the router, only resorting to probing after a
period of silence.

> that the DHCP server is down (or the DHCP client would have to poll). Not
nice.

Is it requirement that ND is in the kernel, and DHCPV6-PD be outside of it?

The Linux kernel signals user space when receiving RAs with DNS options, it
has a kennel space DHCPv4 client, a user space ARP implementation exists,
and Network Manager is moving quite a lot of low level functions like RA
handing into user space.

So I don't think there should be much weight put on whether some functions
are in the kernel while others are in user space.

> its DHCP server. And there are many scenarios where that doesn't happen.

In a DHCPv6-PD scenario, the DHCP server or relay is also the router that
the host receives all or all offlink traffic from. That is also the router
sending RAs, and also one that the host will be tracking the presence of
using NUD.

> effect of that on a large wifi network.

If that is a problem, then their WiFi network is too large.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 21 Dec 2015 10:32:19 +1100

> related APIs that are defined outside the IETF.

What needed to be extended?  HE is basically fast retry and the existing
API supported that.

	https://users.isc.org/~marka/select-connect.c
	https://users.isc.org/~marka/poll-connect.c
	https://users.isc.org/~marka/thread-connect.c
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Dec 2015 17:22:17 +0000

Hi Philip,

> Sent: Saturday, December 19, 2015 5:47 AM
> To: [email-masked]
> Cc: Templin, Fred L

Yes, with AERO the client has to keep in touch with its serving router(s)
and change over to another if the primary one goes down.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Dec 2015 17:23:11 +0000

What Mark is describing is exactly what AERO does.

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Saturday, December 19, 2015 2:48 PM
To: Philip Homburg
Cc: v6ops list
Subject: Re: [v6ops] DHCPv6 PD for hosts (was: draft-ietf-v6ops-host-addr-availability)

> and share persistent state wrt prefix leases.

I think DHCPv6-PD is serving the same or similar function as routing protocols in this scenario, so I think that means that the DHCPv6-PD client needs to track the presence of its DHCP "neighbor" using the standard sorts of neighbor presence discovery methods e.g. link state, neighbor advertisements or probing.

For example, if NUD determines that the current PD router has gone away, a DHCPv6 REBIND is triggered to see if some other available DHCP server will provide/facilitate the delegated prefix.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Dec 2015 17:35:25 +0000

Hi Philip,

> From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Sunday, December 20, 2015 3:03 AM
> To: [email-masked]

This is all implementation details. It is quite possible to implement DHCP
client in the kernel and IPv6 ND in user space. After all, the DHCP client
features that are needed really amount to just a couple of messages.

In the AERO implementation I announced, the DHCP client and IPv6 ND
are implemented in a user process that sits on a TUN/TAP interface. So,
it is in an application yes but it is not really user-level and not really kernel
level - it is somewhere in between.

> its DHCP server. And there are many scenarios where that doesn't happen.

Periodic IPv6 RS/RA probing as keepalives operates even if there is no
traffic flowing. The client is responsible for keeping its association with
the server alive, i.e., the same as for DHCP lease maintenance.

> for scalability. Also not good for battery usage.

30 seconds is a recommended constant. Also, this is no different that what
common vpn clients already do, such as OpenVPN. I haven't really thought
much about extending the length of time between probes, but it could
well be that 30 seconds is far too short for some deployments and too
long for others. That is why it is a configurable constant the same as for
IPv6 ND constants.

> effect of that on a large wifi network.

No, not multicast. With AERO, the client discovers a list of unicast addresses of
potential servers. It picks one or a few of them and does a DHCPv6 PD exchange.
If one or a few go down, it changes over to the unicast address of a new
server. No multicast messaging is used.

> that is something for 6man).

The only addition to IPv6 ND made by AERO is router-to-router redirects, and
that has already been documented in RFC6706. Eveything else is standard
IPv6 ND except unicast and not multicast.

Thanks - Fred