Subject: [homenet] Fwd: I-D Action: draft-baker-6man-multi-homed-host-00.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 10 Aug 2015 14:04:20 +0000

This is actually being discussed in 6man, as the chairs requested it there, but homenet might have comments to pass along.

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: I-D Action: draft-baker-6man-multi-homed-host-00.txt
> Date: August 7, 2015 at 7:40:43 AM PDT
> To: <[email-masked]>
> Reply-To: <[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>       Title           : Host routing in a multi-prefix network
>       Authors         : Fred Baker
>                         Brian Carpenter
> 	Filename        : draft-baker-6man-multi-homed-host-00.txt
> 	Pages           : 6
> 	Date            : 2015-08-07
> 
> Abstract:
>  This note describes expected host behavior in a network that has more
>  than one prefix, each allocated by an upstream network that
>  implements BCP 38 filtering.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-baker-6man-multi-homed-host/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 10 Aug 2015 17:28:44 +0000

Something that homenet, and specifically HNCP, might be interested to consider is the impact of egress/SADR routing as discussed in this draft on its recommendations. The draft is in WGLC and in need of a revised draft, so you may consider this a late comment or a WGLC comment as you please. Or, tell me that the person who raised the question to me is incorrect.

It has been pointed out to me that HNCP expects that every router in a homenet network will advertise every PA or PI prefix in use in the network. This creates two issues.

The recommended host behavior is to have a host that has an address in each of two or more prefixes (which, note, might be on the same interface or on different ones) is to have it originate traffic using a given source prefix to the router, or one of the routers, that advertised the prefix to it. In the simplest case, which would be to have one or more hosts on a LAN with two or more routers connected to as many upstream networks, would have the network avoid BCP 84 routing among the routers, but instead have a host present a packet to the router the packet needs to use.

A more general case is exemplified in my home office. Due to Cisco Information Security rules, my office is effectively part of and served by Cisco's corporate network, while my home is served by my ISP. There is physically one router, but it is configured in two slices, and packets don't travel between the slices. So conceptually - and there is no reason this couldn't be physical - there are two separate routers. If I turn on the WiFi interface on my laptop, I now have a Cisco address on the Ethernet port and an ISP address on the WiFi port. I can expect both Cisco and the ISP to implement BCP 38 (discarding traffic that has the wrong source address), and there is no mechanism or connectivity by which a packet with one of the two prefixes might be redirected (BCP 84) to the other router. I am absolutely dependent on my host guessing correctly - absent this rule. The first issue is that, absent this rule, we are absolutely dependent on Happy Eyeballs processing to even get a packet out of the door.

The second issue, and this one I'm unsure about but raise in case there is an issue, has to do with the process of removing a prefix from a network. It seems likely that we have a counterpart to RIP's count-to-infinity problem, except that there is no counter to rely on. If a router advertising a prefix into a network decides to withdraw it, the last router in the network that maintains knowledge of it has some possibility of re-infecting the network with it. I think you want the advertisement of a prefix in an RA to be tightly linked to its current allocation status and lifetime.

In any event, I would urge the HNCP design team to consider the cases, and either make an argument that making network routing more complex (BCP 84) has a benefit I'm missing and actually works without the rule, or change HNCP to not have each RA contain every possible prefix.

I'll draw a picture to help understand the case. There are two upstream ISPs, which I'll call ISP-Alice and ISP-Bob. In the home, there are two LANs, three routers (Alice, Bob, and Carol), two LANs, and two hosts (Spanky and Alfalfa):

   +---------------+        +--------------+
   |               |        |              |
   |    ISP-Alice  |        |    ISP-Bob   |
   |               |        |              |
   |               |        |              |
   +------+--------+        +-----+--------+
          |                       |
       +--+--+                  +-+-+
       |Alice|                  |Bob|
       +--+--+                  +-+-+
          |                       |
   +----+-+----------+------------+--------+
        |            |
     +--+---+     +--+--+
     |Spanky|     |Carol|
     +------+     +--+--+
                     |
   +----+------------+---------------------+
        |
     +--+----+
     |Alfalfa|
     +-------+

If every router is responsible to announce prefixes from ISP-Alice and ISP-Bob on every LAN, then Spanky has a distinct probability that, to get a packet to ISP-Alice, it will send it to ISP-Bob, who will then have to redirect it to ISP-Alice. If on that LAN, Alice advertises the ISp-Alice prefix and Bob advertises the ISP-Bob prefix, and Spanky presents the packet to the router that advertised its source prefix, Spanky will invariably present such a packet to Alice.

On the second LAN, Carol will of course have to announce both prefixes, and use SADR routing to get the packet to the right egress router. But Alfalfa doesn't need to know the details; he learned both prefixes from Carol and presents all packets to her.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 10 Aug 2015 21:02:22 +0200

> The second issue, and this one I'm unsure about but raise in case there
> is an issue, has to do with the process of removing a prefix from
> a network. It seems likely that we have a counterpart to RIP's
> count-to-infinity problem, except that there is no counter to rely
> on. If a router advertising a prefix into a network decides to withdraw
> it, the last router in the network that maintains knowledge of it has
> some possibility of re-infecting the network with it.

I'm too lazy to fish out the normative text right now, so this is from
memory.

You'll recall that HNCP distinguishes between "delegated prefix" (one that
was given out by your ISP's DHCPv6-PD server) and an "assigned prefix"
(one that was assigned to a link and is being advertised over RA).  Each
assigned prefix must be within a delegated prefix.  As you note, HNCP
recommends that there should be one AP assigned to each link from each DP.

I'm not sure if I read you right, but I assume you are concerned about
what happens when a delegated prefix is retraceted.  (The ISP stops the
delegation, or the DHCPv6-PD client decides to hide the prefix from the
rest of the Homenet).  In that case, the DHCPv6-PD client refloods its set
of delegated prefixes, which triggers the prefix assignment algorithm,
which causes the APs in the retracted DP to be retracted.

If, on the other hand, you are concerned about a router deciding
unilaterally to not assign any prefix from a given AP to a link -- you're
right, this cannot be done, as long as one of the attached routers wants
to assign a prefix, the other routers cannot veto it.  (Each router can
prevent a prefix from being used at all, but it cannot prevent it from
being used just on a single link.)

-- Juliusz

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Aug 2015 12:47:16 -0700

> If every router is responsible to announce prefixes from ISP-Alice and ISP-Bob on every LAN, then Spanky has a distinct probability that, to get a packet to ISP-Alice, it will send it to ISP-Bob, w…

To send a packet through ISP-Alice, it suffices for Spanky to send to any default router on its link that has a source-specific route for ISP-Alice through Alice, which HNCP seems to be capable of insuring that Bob will have if it’s smart enough to be advertising in its RA messages a prefix assigned from one of Alice’s delegations.

Admittedly, this might not be optimal— a direct path from Spanky through Alice to ISP-Alice might perform better, as the section on Residual Issues in the draft notes— but there isn’t any obvious way currently defined to signal to hosts that a particular default router should be preferred over others for packets sourced from addresses corresponding to a Prefix Information Option. It may be tempting to think that conformance with RFC 6724 could help in the case where routers are coordinating to advertise only the assigned prefixes for which they are currently the best default router, but I suspect that it isn’t so simple and serious complications involving topology reconfiguration and RA timeouts can arise.

I think that’s a general problem not specific to HOMENET, and 6MAN should decide what to think about I-D.baker-6man-multi-homed-host accordingly.

—james

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 10 Aug 2015 20:01:04 +0000

> On Aug 10, 2015, at 12:02 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 

OK, that should work.

The first issue stands.

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Aug 2015 22:06:17 +0200

Fred,

Add another LAN interface to Alice, connecting host Porky.
If Alice didn’t advertise both ISP-Alice and ISP-Bob prefixes, Porky couldn’t use ISP Bob.
It would be a quite complicated set of rules determining when Alice should or should not include ISP Bob’s prefixes on a given link. I’m quite uncomfortable tying Router Advertisement PIO’s to routing and topology changes.

I think Brian makes a good point on slide 9:
https://www.ietf.org/proceedings/93/slides/slides-93-6man-6.pdf

  +---------------+        +———————+
  |               |        |              |
  |    ISP-Alice  |        |    ISP-Bob   |
  |               |        |              |
  |               |        |              |
  +------+--------+        +-----+————+
         |                       |
      +--+--+                  +-+-+
      |Alice|                  |Bob|
      +--+--+                  +-+-+
         |                       |
  +----+-+----------+------------+————+
       |            |
    +--+---+     +--+—+
    |Spanky|     |Carol|
    +------+     +--+———+
                    |
  +----+------------+——————————+
       |
    +--+——+
    |Alfalfa|
    +———+

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 11 Aug 2015 10:50:42 +0200 (CEST)

On Mon, 10 Aug 2015, Fred Baker (fred) wrote:

> This is actually being discussed in 6man, as the chairs requested it 
> there, but homenet might have comments to pass along.

>From my point of view, homenet was designed to allow things to work 
without hosts having the functionality described in your document.

So in homenet, there is one router emitting RAs to a LAN for all prefixes 
in the multi-homed homenet. So here the routers do all the work.

Your document describes (in my opinion) desireable behaviour for devices 
going forward. I would like to see text for DHCPv6 as well, both IA_NA and 
IA_PD, if the same kind of behaviour can work there somehow. This is out 
of scope for homenet though.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Aug 2015 19:52:20 +0200

> Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though.

the rule applies regardless of how the addresses have been assigned.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 04:03:17 +0200 (CEST)

> the rule applies regardless of how the addresses have been assigned.

Yes, but how will the router signal that it'll handle addresses for a 
certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is 
being assigned, but that isn't onlink?

Advertising that /56 as an off-link prefix hasn't historically said "I'll 
handle Internet traffic for source addresses within all prefixes that I 
announce, both offlink and on-link". Perhaps we can say that it does, but 
it's not obvious to me that there are no corner cases for this that'll 
break things.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Aug 2015 13:22:41 +0200

Mikael,

> Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink?
> 
> Advertising that /56 as an off-link prefix hasn't historically said "I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link". Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things.

the rule we are proposing is something like:
“In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA”

the subnet model in IPv6 assumed that all routers on a link had equal reachability. this rules solves the case where there are two routers with different reachability (and addressing) on a single link. currently hosts that don’t do implement this, typically suffer from long time outs and broken connectivity.

with the above rule I don’t see how offlink/onlink or DHCPv6 makes any difference. if there isn’t a PIO, well then the host is left uninformed.

can you construct an example where the rule breaks things and that not having the rule wouldn’t?

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 13:32:37 +0200 (CEST)

> “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA”

Check. And PIO here can be RIO as well?

What about if there are several PIO/RIOs of different size, do we do 
longest matching on them to prefer one? Or shortest because the guy with 
the shortest prefix (not /0) is more likely to be the one closest to the 
uplink?

> having the rule wouldn’t?

No, I am still trying to figure out exactly what is being proposed. Next 
step is to try to come up with something that'll make things break.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Aug 2015 14:30:26 +0200

Mikael,

> Check. And PIO here can be RIO as well?

no, I don’t think it can. the RIO says nothing about the link itself.

> What about if there are several PIO/RIOs of different size, do we do longest matching on them to prefer one? Or shortest because the guy with the shortest prefix (not /0) is more likely to be the one closest to the uplink?

two PIO’s of different length on the link sounds like a configuration error.

> No, I am still trying to figure out exactly what is being proposed. Next step is to try to come up with something that'll make things break.

good. ;-)

cheers,
Ole

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 12 Aug 2015 14:44:55 +0200

>> “In SA, DA, NH selection, prefer the NH that has advertised a PIO

It took me a while to decode that.  If anyone else is as stupid as I am,
here's the translation 

  When selecting the (source, destination, next-hop) triple among
  available routes for a given destination prefix, prefer one whose
  next-hop is a router that sent an RA with a prefix that covers the
  source address under consideration.

Ole, Mikael, could either of you please summarise the discussion you're
having for us mere mortals?  I don't understand what problem you're trying
to solve, and I don't understand why you're distinguishing between SLAAC
and DHCPv6.

Sorry for the bother.

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 14:59:29 +0200 (CEST)

> two PIO’s of different length on the link sounds like a configuration 

Then I must still be missing something.

Example time:

A               B+-+F
+               +
|               |
+----+-----+----+
      |     |
      +     +
      C     D
            +
            |
            +
            E

A, B and D are routers. A has received a /56 from ISPA. D has been 
delegated a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising 
a /64 from ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A 
is also advertising ISPA /56 as off-link to indicate that it'll handle the 
entire /56.

Now, C takes itself a couple of addresses from the ABCD /64 (because A=1) 
and does DHCPv6 IA_NA. A then hands it an address from outside the /64 
(because that was configured for some reason). A has a /120 route pointing 
to its interface that ABCD sits on, so that this DHCPv6 IA_NA works 
(because it's outside the on-link /64).

D is a RFC7084 router and has requested IA_PD from A and received another 
/64, which it then uses to put on the DE link.

Now, do we want D to do anything to tell C that E is reachable through D? 
Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing 
and let all traffic from C to D bounce via A? Do we want A to in some way 
announce the delegated /64 IA_PD prefix?

What do we want A to do, should it announce the /120 as off-link? On-link 
might make sense in this case.

B has F behind it, I guess we want this to get an address as well, from 
ISPA prefix. Do we want B to send out an RIO for this /64?

So for C, the world view might now look like this:

/56 RIO or PIO (depending on what we want to do) for ISPA prefix
/64 on-link PIO from A for the on-link ABCD /64 prefix
/120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix
/64 RIO (?) from D for its DE /64
/64 RIO (?) from B for its BF /64

Or do we want above RIOs to be off-link PIOs instead?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 15:02:19 +0200 (CEST)

On Wed, 12 Aug 2015, Juliusz Chroboczek wrote:

> having for us mere mortals?  I don't understand what problem you're 
> trying to solve, and I don't understand why you're distinguishing 
> between SLAAC and DHCPv6.

Because a DHCPv6 IA_NA and DHCPv6 IA_PD doesn't have to be covered by an 
on-link prefix.

You don't get any SLAAC based addresses without an on-link RA for the 
prefix with A=1. So this is obvious that there needs to be an RA sent.

For DHCPv6 these contraints do not apply anymore. That's what I'm trying 
to figure out, how do we handle these IA_NAs and IA_PDs that are not 
within an on-link RA being sent for that prefix.

This is definitely not a configuration error, it's perfectly valid to hand 
out single address using DHCPv6 IA_NA that isn't covered by an off-link or 
on-link prefix.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 12 Aug 2015 15:59:38 +0000

> On Aug 12, 2015, at 5:44 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 

For the record, I'm having the same question. To my way of thinking, we have effectively two or more routing systems (able to get messages to each relevant upstream network, for reasons that might be physical or virtual in nature), and a single client (the host in question). The host chose a source address (RFC 6724) and needs to hand a packet to the routing system using that address as a source.

We could involve the host in a full-blown routing implementation, trying to micro-optimize routes through the default-free zone from a host that probably has a grand total of two default routes in its route table, but haven't historically chosen to do that.

The fact that neither of us even understands the sentence says, to me, that there is a whole lot of complexity going on that probably isn't necessary...

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Aug 2015 20:18:15 +0200

Juliusz,

>  source address under consideration.

thanks for the readable version! ;-)
now, can you please write one for hosts that only have a Default Router List (as in no routing table).
(I don’t object if we only describe the conceptual host model for type C (4191) hosts though.

> to solve, and I don't understand why you're distinguishing between SLAAC

I’ll try.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Aug 2015 20:25:45 +0200

Mikael,

>> Ole, Mikael, could either of you please summarise the discussion you're having for us mere mortals?  I don't understand what problem you're trying to solve, and I don't understand why you're distinguishing between SLAAC and DHCPv6.
> 
> Because a DHCPv6 IA_NA and DHCPv6 IA_PD doesn't have to be covered by an on-link prefix.
> 
> You don't get any SLAAC based addresses without an on-link RA for the prefix with A=1. So this is obvious that there needs to be an RA sent.

RA’s are sent regardless of DHCP or SLAAC.
you can do SLAAC with A=1, L=0.

> For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and IA_PDs that are not within an on-link RA being sent for that prefix.

I take it IA_PD was included above by mistake.

> This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't covered by an off-link or on-link prefix.

true. but I’m not sure what bearing that has with the host rule in question.
I’m also wondering if you are making a wrong assumption of what an L=0 PIO entails.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 20:42:47 +0200 (CEST)

> I take it IA_PD was included above by mistake.

No.

> I’m also wondering if you are making a wrong assumption of what an L=0 PIO entails.

I don't know. Am I?

I still don't understand what a host with an IA_NA or IA_PD that isn't 
covered by an on-link PIO should do with a packet sourced from those 
IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case.

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Aug 2015 20:54:27 +0200

Mikael,

in the land of contrived examples! :-)
this working groups answer to the below is make this a homenet and run HNCP. then the host rule enhancement isn’t used.
in any case let me try to reply below, although I’m quite confused about the example.

> A, B and D are routers. A has received a /56 from ISPA. D has been delegated a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising a /64 from ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A is also advertising ISPA /56 as off-link to indicate that it'll handle the entire /56.

currently, advertising a PIO with L=0 isn’t a routing advertisement (“handle the prefix”?). it only affects a hosts prefix list and how it does onlink determination for addresses in that prefix. i.e. a host would first chose D and NH, then find a suitable source.
with the new rule, the PIO becomes more like a source constrained route. “for any source address matching prefix in PIO, send traffic to me”.

I don’t understand what you would gain from the ISPA/56 PIO over the ISPA/64 you’d have in C already.

> Now, C takes itself a couple of addresses from the ABCD /64 (because A=1) and does DHCPv6 IA_NA. A then hands it an address from outside the /64 (because that was configured for some reason). A has a /120 route pointing to its interface that ABCD sits on, so that this DHCPv6 IA_NA works (because it's outside the on-link /64).
> 
> D is a RFC7084 router and has requested IA_PD from A and received another /64, which it then uses to put on the DE link.
> 
> Now, do we want D to do anything to tell C that E is reachable through D? Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing and let all traffic from C to D bounce via A? Do we want A to in some way announce the delegated /64 IA_PD prefix?

1) run homenet / routing protocol
2) absolutely not
3) RIO with router lifetime of 0 could work but geez this is what homenet solves
4) yes
5) no

> What do we want A to do, should it announce the /120 as off-link? On-link might make sense in this case.

that would only affect hosts on the ABCD link. D would still send all traffic for the /120 to A (as default route)

> B has F behind it, I guess we want this to get an address as well, from ISPA prefix. Do we want B to send out an RIO for this /64?

you want B to run homenet.

> /56 RIO or PIO (depending on what we want to do) for ISPA prefix

I don’t see that you need either.

> /64 on-link PIO from A for the on-link ABCD /64 prefix

yes.

> /120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix

possibly. probably not needed.

> Or do we want above RIOs to be off-link PIOs instead?

they would be RIOs. since you want destination routes, and not source routes.

in (D,S) SADR notation. a RIO:

(DE/64, *)

while PIO:

(::/0, DE/64)

please use homenet protocols. don’t build networks like this!

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Aug 2015 21:15:24 +0200

Mikael,

>> I take it IA_PD was included above by mistake.

an IA_PD prefix is by definition not assigned to the link between RR and DR.

> I still don't understand what a host with an IA_NA or IA_PD that isn't covered by an on-link PIO should do with a packet sourced from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case.

are you talking about something different than 3633 DHCPv6 prefix delegation?

if the SA doesn’t match a PIO on link, then the next-hop on that interface is chosen like it is today.

if you’re inventing new stuff like host IA_PD derived addresses, then that’s something someone has to specify.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Aug 2015 13:53:57 +1200

Below...
On 13/08/2015 06:42, Mikael Abrahamsson wrote:
>>> For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and
>>> IA_PDs that are not within an on-link RA being sent for that prefix.
>>
>>> This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't
>>> covered by an off-link or on-link prefix.
>>
> I still don't understand what a host with an IA_NA or IA_PD that isn't covered by an on-link PIO should do with a packet sourced
> from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case.

I think we're saying: there needs to be a PIO if it matters which first-hop
router such a host picks. If it doesn't matter (i.e. there is a complete local
routing cloud with SADR, or there is no BCP 38 filter) then the host can
use any first-hop router it wants.

How the router knows to send that PIO is not a problem for the host,
therefore not in scope in this draft. (But there's no doubt in my mind that
life is simpler if you don't use DHCPv6.)

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 Aug 2015 07:23:31 +0200 (CEST)

> use any first-hop router it wants.

Can it be an L=0 PIO?

> life is simpler if you don't use DHCPv6.)

Of course, but the use-case of having IA_NA that isn't covered by an 
on-link PIO Is useful in some scenarios (where for instance you have 
configured the L2 network so that devices can't talk directly to each 
other, and you want to make the L3 configuration reflect this so you don't 
have to do magic tricks like local-proxy-arp (whatever that would be 
called in IPv6)).

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 Aug 2015 09:02:29 +0200 (CEST)

> I don’t understand what you would gain from the ISPA/56 PIO over the ISPA/64 you’d have in C already.

Because the DHCPv6 IA_NAs handed out to C (by A or a DHCPv6 server on the 
ABCD link) isn't in any on-link PIO. So without the /56, C has no idea it 
needs to send these packets to A to avoid BCP38 filtering (in case for 
instance B is announcing ISPB prefixes).

>> Now, do we want D to do anything to tell C that E is reachable through 
>> D? Like announce in RAs an off-link /64? Or announce an RIO? Or do 
>> nothing and let all traffic from C to D bounce via A? Do we want A to 
>> in some way announce the delegated /64 IA_PD prefix?
>

That won't tell C anything, but ok, fine.

> that would only affect hosts on the ABCD link. D would still send all traffic for the /120 to A (as default route)

Yes.

> I don’t see that you need either.

How will C know whereto send packets sourced from its IA_NA address?

> possibly. probably not needed.

How will C know whereto send packets sourced from its IA_NA address?

As far as I can tell, you need either covering /56 or announcing the /120 
(remember, this /120 it not within a /64 that there is a PIO for if you 
don't announce the /56 as an L=0 PIO).

Again, my problem is that I don't see how IA_NA (or IA_PD in case it's a 
router) outside encompassing PIO can get correctly routed. And again, this 
is a valid deployment scenario. So either we say "MUST announce PIO with 
L=0 or L=1 for all addresses that a host will have, or things will not 
work".

I also want to be able to solve RFC7084-style DHCPv6 IA_PD requesting 
router to send packets from hosts behind it to the correct upstream, so I 
would like this case adressed as well.

Announcing the entire PIO /56 L=0 that the A router has been delegated 
would solve this problem, yes? And if there is a /56 and /64 that are 
overlapping, do longest prefix matching on the PIO and choose that NH.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Aug 2015 14:37:34 +1200

>> use any first-hop router it wants.

I would think so. L=0 conveys no information, after all,
according to RFC 4861: "When not set the advertisement makes
no statement about on-link or off-link properties of the prefix."

So I think the -01 draft is wrong, since it says "on-link."

    Brian

> Of course, but the use-case of having IA_NA that isn't covered by an on-link PIO Is useful in some scenarios (where for instance
> you have configured the L2 network so that devices can't talk directly to each other, and you want to make the L3 configuration
> reflect this so you don't have to do magic tricks like local-proxy-arp (whatever that would be called in IPv6)).
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 14 Aug 2015 02:46:38 +0000

> On Aug 13, 2015, at 7:37 PM, Brian E Carpenter <[email-masked]> wrote:
> 

What is says is

   A host receives prefixes in a Router Advertisement [RFC4861], which
   goes on to identify whether they are usable by SLAAC [RFC4862]
   [RFC4941] [RFC7217].  When no prefixes are usable for SLAAC, the
   Router Advertisement would normally signal the availability of DHCPv6
   [RFC3315] and the host would use it to configure its addresses.  In
   the latter case it will be generally the case that the configured
   addresses match one of the prefixes advertised in a Router
   Advertisement that are supposed to be on-link in that subnet.

   Since the host derives fundamental default routing information from
   the Route Advertisement, this implies that, in any network with hosts
   using multiple prefixes, each prefix SHOULD be advertised via on-link
   Prefix Information Options [RFC4861] by one of the attached routers,
   even if addresses are being assigned using DHCPv6.  A router that
   advertises a prefix indicates that it is able to appropriately route
   packets with source addresses within that prefix.

Tell me what to make it say.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Aug 2015 15:21:22 +1200

> Tell me what to make it say.

I think all we have to do is delete 'on-link' in the second paragraph.
(The 'generally' in the first paragraph allows for the exceptional
case that Mikael was concerned about, I think.)

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 14 Aug 2015 06:37:55 +0000

> On Aug 13, 2015, at 8:21 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I'll give people a couple of days to comment further, but that change is locked into the next version.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 15 Aug 2015 12:58:23 +0200

>> 	Filename        : draft-baker-6man-multi-homed-host-00.txt

I find the structure of this document puzzling.  Shouldn't Section 4 be
moved before Section 3, so that current sections 2 and 4 become 2.1 and 2.2?

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Aug 2015 09:07:29 +1200

> moved before Section 3, so that current sections 2 and 4 become 2.1 and 2.2?

Possibly. We do want to be sure that the routing community takes note of
the current Section 4, which is why it is separate despite being very short.

Thanks
    Brian

---

From: Steven Barth <[email-masked]>
Date: Sun, 16 Aug 2015 11:31:55 +0200

> In any event, I would urge the HNCP design team to consider the cases, and either make an argument that making network routing more complex (BCP 84) has a benefit I'm missing and actually works wit…

After scanning the discussions here, is there anything in particular that people feel which we need to add or clarify in HNCP for that matter?

It seems to me that the current behavior, i.e., potentially "non-optimal" router sending out the PIO
and then relying on redirection / routing does not really break things. Optimizing the PIO sending might in theory be
possible but - as pointed out - is probably very hard to accomplish in practice.

In addition, as a personal note from my own reading, I'm not 100% convinced that hosts even following the next-hop
tracking of 6724 would correctly react to potential "handover" of a PIO from one router to another since the definition
is relatively vague.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Aug 2015 08:38:53 +1200

On 16/08/2015 21:31, Steven Barth wrote:
> and then relying on redirection / routing does not really break things. 

I think Pierre was saying in Prague that it does break things in the case
of extra hops on very lossy wireless networks.

> Optimizing the PIO sending might in theory be

That is probably true today but hopefully doesn't have to stay true
for the next hundred years.

    Brian

---

From: Steven Barth <[email-masked]>
Date: Mon, 17 Aug 2015 16:19:00 +0200

Hi Fred,

a few comments:

"A host receives on-link prefixes in a Router Advertisement [...] to identify preference order among them"
Is there really a preference order? Also I think off-link prefixes are similarly usable for address assignment
or DHCPv6, they are simply not "on-link".

"apart from the fact that it is emitting Router Advertisements (RAs)." -
wasn't there also a router flag in ND at some point? anyway.

"One might expect that the routers may or may
   not receive each other's RAs and form an address in the other
   router's prefix."

Funny enough in theory 4862 says "The autoconfiguration process specified in this document applies only
   to hosts and not routers."

"Since the host derives fundamental default routing information from
   the RA, this implies that, on any network with multiple prefixes,
   each prefix SHOULD be advertised by one of the attached routers, even
   if addresses are being assigned using DHCPv6."

Hmm, I don't really see the connection between prefixes and (default)
routing information here, since for non source-dest-capable hosts
the prefixes do not matter for routing. Or os this sort of a foreshadowing
of 6724 Rule 5.5?

"A host SHOULD select a "default gateway" for each prefix it uses to
   obtain one of its own addresses.  That router SHOULD be one of the
   routers advertising the prefix in its RA.  As a result of doing so,
   when a host emits a datagram using a source address in one of those
   prefixes and has no history directing it otherwise, it SHOULD send it
   to the indicated "default gateway"."

The question is to which one (if there are multiple): this might be important
for e.g. fail-over cases or if you want to dynamically optimize away that extra
hop you mention.

"The direct implication of Section 2 is that routing protocols used in
   multihomed networks SHOULD be capable of source-prefix based egress
   routing, and that multihomed networks SHOULD deploy them."

This confuses me a bit since Section 2 said "Because there is no routing
protocol among those routers" and now suddenly there seems to be one?

Cheers,

Steven

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Aug 2015 11:02:05 +1200

Hi Steven,

> the prefixes do not matter for routing. Or os this sort of a foreshadowing

Not really. Rule 5.5 affects source address selection. We are assuming
that source selection has already happened, and the next job is choosing
the first-hop router. We need both.

> protocol among those routers" and now suddenly there seems to be one?

There are two scenarios: disjoint routing and a single routing cloud.
I think the diagrams now make that fairly clear, and moving section 4 to
be section 2.2 (as Juliusz suggested) will make the logic easier
to follow.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Aug 2015 09:21:12 +0200

> for e.g. fail-over cases or if you want to dynamically optimize away that extra

yes, that text should be changed to accommodate multiple default routers.
ref rfc4311.

cheers,
Ole