Subject: RE: ipv6 Digest, Vol 136, Issue 30

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 20 Aug 2015 14:00:07 +0000

5. Re: New Version Notification for
      draft-baker-6man-multi-homed-host-01.txt (Brian E Carpenter)
>> For the main purpose of this draft, the
>> most important thing is to choose the right default router for a given
>> source address, right?  In that sense, the more important part of
>> Section 3 is the third paragraph:
>> 
>>    A host SHOULD select a "default gateway" for each source prefix it
>>    uses to form an address or is assigned an address in.  [...]
>
>Agreed.
>
 >   Brian

Isn't that reverse? Isn't RFC 6724 Rule 5.5 about the selection of the next hop to the destination D first? Once the next hop is known, the sender can select the right source address based on the prefix the next hop advertised. When sending very first packet, how can a sender find out which next hop to use to get to D?

Thanks,
Dusan Mudric.

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, August 20, 2015 5:37 AM
To: [email-masked]
Subject: ipv6 Digest, Vol 136, Issue 30

Send ipv6 mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=d1zVpuzrviDdDNFIpfmM2hYk5YfxNTIDsgN3f1BnBRU&e=
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6 digest..."

Today's Topics:

   1. I-D Action: draft-ietf-6man-default-iids-06.txt
      ([email-masked])
   2. Re: I-D Action: draft-ietf-6man-default-iids-06.txt
      (Fernando Gont)
   3. I-D Action: draft-ietf-6man-default-iids-07.txt
      ([email-masked])
   4. Re: I-D Action: draft-smith-6man-link-locals-off-link-00.txt
      (Dennis Ferguson)
   5. Re: New Version Notification for
      draft-baker-6man-multi-homed-host-01.txt (Brian E Carpenter)
   6. Re: New Version Notification for
      draft-smith-6man-link-locals-off-link-00.txt (Mark Smith)

----------------------------------------------------------------------

Message: 1
Date: Wed, 19 Aug 2015 12:30:05 -0700
From: [email-masked]
To: <[email-masked]>
Cc: [email-masked]
Subject: I-D Action: draft-ietf-6man-default-iids-06.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Recommendation on Stable IPv6 Interface Identifiers
        Authors         : Fernando Gont
                          Alissa Cooper
                          Dave Thaler
                          Will Liu
	Filename        : draft-ietf-6man-default-iids-06.txt
	Pages           : 10
	Date            : 2015-08-19

Abstract:
   The IPv6 addressing architecture defines Modified EUI-64 format
   Interface Identifiers, and the existing IPv6 over various link-layers
   specify how such identifiers are derived from the underlying link-
   layer address (e.g., an IEEE LAN MAC address) when employing IPv6
   Stateless Address Autoconfiguration (SLAAC).  The security and
   privacy implications of embedding link-layer addresses in the
   Interface Identifier have been known and understood for some time
   now, and some popular IPv6 implementations have already deviated from
   such schemes to mitigate these issues.  This document changes the
   recommended default Interface Identifier generation scheme for SLAAC
   to that specified in RFC7217, and recommends against embedding link-
   layer addresses in IPv6 Interface Identifiers.  It formally updates
   RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590,
   RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and
   RFC5121, which require IPv6 Interface Identifiers to be derived from
   the underlying link-layer address.  Additionally, this document
   provides advice about the generation of Interface Identifiers with
   other address configuration mechanisms, such as Dynamic Host
   Configuration Protocol version 6 (DHCPv6) and manual configuration.

The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2D6man-2Ddefault-2Diids_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=AC2RbC-tzDyuVNCy3dYYJLnJGfynzmACcp8hQyHy2tM&e= 

There's also a htmlized version available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6man-2Ddefault-2Diids-2D06&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=cnUZe-IjtJapyKlzw3p_KsW5CVWA1VCncexzXTeSGhA&e= 

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2D6man-2Ddefault-2Diids-2D06&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=OUC-rSTPVRrQBYDoCdb4ENvyC_-ksV3X9-tsuFCS5i0&e= 

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:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=Jr00RRYNT3rfDfa6jbrZL8NsMDUgcw_7y0_W_EtEmd4&e= 

------------------------------

Message: 2
Date: Wed, 19 Aug 2015 22:57:47 +0200
From: Fernando Gont <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-06.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252

Hi, Bob & Ole,

This version should be ready to ship.

Thanks!

Best regards,
Fernando

On 08/19/2015 09:30 PM, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
> 
>         Title           : Recommendation on Stable IPv6 Interface Identifiers
>         Authors         : Fernando Gont
>                           Alissa Cooper
>                           Dave Thaler
>                           Will Liu
> 	Filename        : draft-ietf-6man-default-iids-06.txt
> 	Pages           : 10
> 	Date            : 2015-08-19
> 
> Abstract:
>    The IPv6 addressing architecture defines Modified EUI-64 format
>    Interface Identifiers, and the existing IPv6 over various link-layers
>    specify how such identifiers are derived from the underlying link-
>    layer address (e.g., an IEEE LAN MAC address) when employing IPv6
>    Stateless Address Autoconfiguration (SLAAC).  The security and
>    privacy implications of embedding link-layer addresses in the
>    Interface Identifier have been known and understood for some time
>    now, and some popular IPv6 implementations have already deviated from
>    such schemes to mitigate these issues.  This document changes the
>    recommended default Interface Identifier generation scheme for SLAAC
>    to that specified in RFC7217, and recommends against embedding link-
>    layer addresses in IPv6 Interface Identifiers.  It formally updates
>    RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590,
>    RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and
>    RFC5121, which require IPv6 Interface Identifiers to be derived from
>    the underlying link-layer address.  Additionally, this document
>    provides advice about the generation of Interface Identifiers with
>    other address configuration mechanisms, such as Dynamic Host
>    Configuration Protocol version 6 (DHCPv6) and manual configuration.
> 
> 
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.
> org_doc_draft-2Dietf-2D6man-2Ddefault-2Diids_&d=BQICAg&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDuc
> qeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=AC2RbC-tzDyuVNCy3dYYJLnJGfynzmACcp8h
> QyHy2tM&e=
> 
> There's also a htmlized version available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_draft-2Dietf-2D6man-2Ddefault-2Diids-2D06&d=BQICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucq
> eiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=cnUZe-IjtJapyKlzw3p_KsW5CVWA1VCncexzX
> TeSGhA&e=
> 
> A diff from the previous version is available at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcd
> iff-3Furl2-3Ddraft-2Dietf-2D6man-2Ddefault-2Diids-2D06&d=BQICAg&c=BFpW
> Qw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzF
> l9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=OUC-rSTPVRrQBYDoCdb4ENvyC_-
> ksV3X9-tsuFCS5i0&e=
> 
> 
> 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:
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_intern
> et-2Ddrafts_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhI
> oUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s
> =Jr00RRYNT3rfDfa6jbrZL8NsMDUgcw_7y0_W_EtEmd4&e=
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_ipv6&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3
> iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZC
> UGg&s=d1zVpuzrviDdDNFIpfmM2hYk5YfxNTIDsgN3f1BnBRU&e=
> --------------------------------------------------------------------
> 

--
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

------------------------------

Message: 3
Date: Wed, 19 Aug 2015 14:46:12 -0700
From: [email-masked]
To: <[email-masked]>
Cc: [email-masked]
Subject: I-D Action: draft-ietf-6man-default-iids-07.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Recommendation on Stable IPv6 Interface Identifiers
        Authors         : Fernando Gont
                          Alissa Cooper
                          Dave Thaler
                          Will Liu
	Filename        : draft-ietf-6man-default-iids-07.txt
	Pages           : 10
	Date            : 2015-08-19

Abstract:
   The IPv6 addressing architecture defines Modified EUI-64 format
   Interface Identifiers, and the existing IPv6 over various link-layers
   specify how such identifiers are derived from the underlying link-
   layer address (e.g., an IEEE LAN MAC address) when employing IPv6
   Stateless Address Autoconfiguration (SLAAC).  The security and
   privacy implications of embedding link-layer addresses in the
   Interface Identifier have been known and understood for some time
   now, and some popular IPv6 implementations have already deviated from
   such schemes to mitigate these issues.  This document changes the
   recommended default Interface Identifier generation scheme for SLAAC
   to that specified in RFC7217, and recommends against embedding link-
   layer addresses in IPv6 Interface Identifiers.  It formally updates
   RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590,
   RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and
   RFC5121, which require IPv6 Interface Identifiers to be derived from
   the underlying link-layer address.  Additionally, this document
   provides advice about the generation of Interface Identifiers with
   other address configuration mechanisms, such as Dynamic Host
   Configuration Protocol version 6 (DHCPv6) and manual configuration.

The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2D6man-2Ddefault-2Diids_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=AC2RbC-tzDyuVNCy3dYYJLnJGfynzmACcp8hQyHy2tM&e= 

There's also a htmlized version available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6man-2Ddefault-2Diids-2D07&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=_YqIUewPT27HzSLqMWy27dk8dZb4G7uO1YNJxPppPsc&e= 

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2D6man-2Ddefault-2Diids-2D07&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=YM6D65uLQypKtRGYycCDhhWn2_cHyHLEC_inkGfS0No&e= 

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:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=Jr00RRYNT3rfDfa6jbrZL8NsMDUgcw_7y0_W_EtEmd4&e= 

------------------------------

Message: 4
Date: Wed, 19 Aug 2015 18:16:58 -0700
From: Dennis Ferguson <[email-masked]>
To: Mark Smith <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: I-D Action: draft-smith-6man-link-locals-off-link-00.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Hello,

On 19 Aug, 2015, at 00:41 , Mark Smith <[email-masked]> wrote:
> On 19 August 2015 at 12:20, Brian E Carpenter
> <[email-masked]> wrote:
>> I have a question.
>> 
>> How did the host that is attempting to send a packet to its
>> unreachable neighbour learn the address of that neighbour
>> in the first place? As far as I can see, neighbour discovery is
>> clearly going to fail anyway, since neither Neighbor Solicitation
>> nor Neighbor Advertisement will be delivered.
>> 
> 
> Right. The failure to resolve the link-local address will cause the
> application to fail to connect, unlike on a conventional
> (unconstrained) broadcast multi-access, NBMA or point-to-point link
> where link-locals work.

I'm confused about how this answers the question, though.  If I write
down the link-local address of a machine attached to my (unconstrained)
broadcast multiaccess network at home, go to work and try to connect
to the same machine using that address, it will fail to connect.  The
reason it will fail to connect is that the host I'm trying to connect
to using that link-local address is off-link, just like most other hosts
on the planet are.  Link-local addresses don't work if the hosts are
off-link, a fact that is entirely unsurprising and is not in need of
fixing, so applications which need to talk to off-link destinations
will need to avoid trying to use link-local addresses to do so.

So I think the question remains: what made the application trying to
connect to an off-link destination using a link-local address think
that this should work?

What is "on-link" and what is "off-link" is neither arbitrarily determined
nor defined by addressing, it is a property of the L2 connectivity that
exists.  Once whatever is necessary for address resolution has been done
a host can expect that a packet sent to an on-link neighbor with a TTL of
255 will arrive with a TTL of 255, that a packet sent with a TTL of 1
will arrive, and that it may be able to continue to talk to an on-link
neighbor even if the routers go away.  An application which doesn't care
about any of this also needn't care what kind of address it uses to talk
to its neighbor and can just pick one that works, but an application which
goes out its way to use a link-local address may very well rely on the
nature of the service it expects to get by limiting itself to on-link
neighbors this way and I think that connection should probably fail if the
expected service can't be delivered.

I think I understand the bigger problem you are trying to solve.  The hosts
and the routers have asymmetric views of what is on-link and what is off-link:
from the point-of-view of a host it is on a link with a router or two but
nothing else, while the routers see themselves as on-link with everything
so behavior somewhere will need to change to deal with the asymmetry.
What I don't get is why you seem to want to change the host behavior to
be more consistent with the router's view of the link, rather than just
limiting the changes to make the router's behavior consistent with the
hosts' view.  Not only is the router the preferred place to deal with
oddities, since there are usually fewer of them than hosts and we already
expect to have to configure them to do stuff in any case, but in this
case the changes in the router will involve making the router behave
(from the hosts' point of view) as if the router has more limited L2
connectivity than it actually does, which can sometimes be done, while
making the host conform to the router's view requires making the hosts
behave is if they have more extensive L2 connectivity than they actually
do, which is impossible.  The L2 connectivity the hosts have is all
they have to work with, so I think you must make the routers behave
consistently with the host view of their link.

To do that I think you would want to make modifications to the router behavior
like the following:

- When the router forwards a packet from one host to another it should
  not send a redirect pointing the source host directly at the destination.
  While doing so might be consistent with the router's view of the link
  it is inconsistent with the host's.

- When the router receives a packet from a host destined to a link-local
  address of another host it should drop the packet.  While this might
  be same-link forwarding from the router's view of the link it is off-link
  forwarding from the point of view of both hosts, so to be consistent
  with the host view it shouldn't be done.

- When the router receives an unrouted multicast from a host it should
  not attempt to deliver that packet to other hosts.  Unrouted
  multicasts don't leave the link they were sent on so doing this would
  be inconsistent with the hosts' view of their links (not to mention
  inconsistent with the router's view as well).

- I think a multicast router is going to have a problem with this link
  if it can't omit the originating host when flooding to the others.
  You'll need to decide if you care or not.

I'm not positive, but I think most what you seem to want to do works (if you
don't need to deal with IPv4) without changes to the hosts if you just let
each host believe it is alone on a link with a router or two, and don't
let the routers do anything inconsistent with that.  Is there a reason
not to do it this way?

Dennis Ferguson

------------------------------

Message: 5
Date: Thu, 20 Aug 2015 15:10:01 +1200
From: Brian E Carpenter <[email-masked]>
To: ???? <[email-masked]>, "Fred Baker (fred)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: New Version Notification for
	draft-baker-6man-multi-homed-host-01.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=utf-8

On 20/08/2015 05:32, ???? wrote:
> At Wed, 19 Aug 2015 05:17:46 +0000,
> "Fred Baker (fred)" <[email-masked]> wrote:
> 
>> Before I post this, I want to collect any remaining comments on
>> it. Your thoughts?
> 
>> 3.  Reasonable expectations of the host
> [...]
>>    When a host makes a successful exchange with a remote address or
>>    prefix using a particular source address, and the host has received a
>>    PIO that matches that source address in an RA, then the host SHOULD
>>    include the prefix in such history, whatever the setting of the L and
>>    A flags in the PIO.  On subsequent attempts to communicate with that
>>    remote address, if it has an address in that prefix at that time, a
>>    host MAY use an address in the remembered prefix for the session.
> 
> As I commented in the relevant discussion on this list, I think
> "whatever the setting of the L and A flags in the PIO" will need some
> explicit note about the unusual case of L=0 and A=0.  For example, we
> might add the following paragraph to the above one:
> 
>    Note that the PIO used this way may have both L and A flags
>    cleared.  Although this does not violate the existing standard,
>    such a PIO has made no sense in practice, and it is possible that
>    existing host implementations simply ignore such a PIO or that a
>    router implementation rejects such a PIO as a configuration error.
>    Newer implementations that support this proposal will need to be
>    update: a host SHOULD NOT ignore a PIO simply because both L and A
>    flags are cleared; a router SHOULD be able to send such a PIO.

Works for me.

> 
> But...on seeing another discussion in this thread from implementor's
> perspective, I now wonder whether we really need to remember a
> "prefix" in this "history".  

And I wonder whether it should be per-source-address rather than
per-source-prefix (just to avoid having to figure out which prefix
an address matches as part of the sending code). In fact it's like
a locally-synthesised redirect (see the code fragment that Pierre
pointed us to at https://urldefense.proofpoint.com/v2/url?u=http-3A__lxr.free-2Delectrons.com_source_net_ipv6_route.c-23L1285&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=va6U3i1jf6Xi9hkeu3rtmfiTNT_w3CP-GXrxPcnPVjA&e= ).

> For the main purpose of this draft, the
> most important thing is to choose the right default router for a given
> source address, right?  In that sense, the more important part of
> Section 3 is the third paragraph:
> 
>    A host SHOULD select a "default gateway" for each source prefix it
>    uses to form an address or is assigned an address in.  [...]

Agreed.

    Brian

> 
> and I suspect this is much easier to implement: this is basically just
> about next hop determination, and what a host implementation should do
> is to remember the sender(s) of RA for each advertised prefix, and to
> choose a router (if any) that advertises a prefix matching the source
> address.  The "history" thing may be an additional useful
> optimization, but that's not the crucial part of the proposal.  If my
> understanding so far is correct and we can agree that it wouldn't be
> that hard to implement just the next hop selection, I'm willing to
> provide more specific text to revise the whole section based on this
> observation.
> 
> --
> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=d1zVpuzrviDdDNFIpfmM2hYk5YfxNTIDsgN3f1BnBRU&e= 
> --------------------------------------------------------------------
> 

------------------------------

Message: 6
Date: Thu, 20 Aug 2015 19:36:32 +1000
From: Mark Smith <[email-masked]>
To: Ole Troan <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: New Version Notification for
	draft-smith-6man-link-locals-off-link-00.txt
Message-ID:
	<CAO42Z2zsgaOK4czwLiOfx1DhdonZQ=6VqsxME=[email-masked]>
Content-Type: text/plain; charset=UTF-8

Hi Ole,

On 19 August 2015 at 20:15, Ole Troan <[email-masked]> wrote:
> Hi Mark,
>
>>> I have to admit some scepticism about this subnet model.
>>> I could sort of understand the justification for it for IPv4, but why do you need it for IPv6?
>>> if you need L3 isolation, why pretend that nodes share the same subnet?
>>
>> I don't think people are actually wanting L3 isolation. I think what
>> they want is the first hop device for all traffic, which can inspect
>> the traffic for security reasons. If the traffic passes the security
>> checks, and the destination is on the link it received it from, it
>> sends it back out the same interface.
>
> 1:N model: put many subscribers on the same L2, then add stateful filtering functions in Ethernet bridges to ensure what?s effectively a unidirectional point to point link to the first-hop router. the bridges are essentially layer violating middleboxes dynamically creating state based on snooping DHCP and ND.
>
> is that a fair description of the 1:N model?
>

Yes. I didn't think they were doing or didn't think it was necessary
to do any layer violation to achieve this in TR-101 networks, as it
hasn't been necessary in Private VLANs.

I think it is probable that snooping of DHCP and ND/ARP is necessary
for IPv4 because there is no commonly known or implemented way of
expressing that addresses within the IPv4 subnet are "off-link" or
reachable via the default router. (I think there might be a way, if
you tell the IPv4 host that it's subnet mask is a /32, then it should
consider all destinations "off-link" or reachable via it's default
router, but I haven't tested it much (I know you can statically
configure that setup on Linux).)

> (I?m not a big fan as you can tell. ;-))
>

So I don't like the idea of layer violations either, however I like
the idea of N:1 a lot more than the alternative of 10s of 1000s of
PPPoE sessions, with their own IPv6 subnets and therefore their own
individual RAs and their own individual RA timers etc.

On the IPv6 broadband deployment I worked on a number of years back,
our BRAS/BNG was carrying 30 000 subscribers. Even with the RA
unsolicited interval wound out the current maximum of 30 minutes, that
meant sending 16 different RAs per second. Probably not a significant
control plane load, but compared to being able to send a single
periodic unsolicited multicast RA with the same PIOs to all of those
30K subs, it is.

>> IPv6 hosts assume non-Link-Local destinations are off-link, unless
>> informed otherwise by the L bit in the PIOs, meaning that the default
>> router(s) are in a position to inspect intra-link IPv6 traffic for
>> non-Link-Local destinations. In other words, ULA and GUA traffic can
>> and will reach other hosts sharing the same link, not directly over
>> the link, but indirectly via a router attached to the link. So there
>> is no layer 3 host isolation occurring if ULA or GUA addresses are
>> used.
>>
>> That fails for Link-Local destinations on CBMA links because hosts
>> assume Link-Locals are on-link.
>
> proxy ND?
>

So proxy ND would be the way to legacy hosts that don't implement what
I've proposed.

There are of course costs:

- hosts are maintaining individual ND entries for their Link-Local
destinations, all pointing to the same link-layer address, and are
performing NUD on each and every one of those entries, which would
load to the router performing proxy ND's control plane.

- hosts are sending multicast NSes for any Link-Local destinations,
increasing the number of multicasts

- the router performing proxy ND either has to listen to all
multicasts to receive NSes for LLs it is proxying for, although it
could be a bit smart and only listen for multicasts to the solicited
node groups that hosts have joined

>> My proposal is to be able to inform hosts that Link-Local destinations
>> are "off-link" too, so that Link-Local traffic is also sent via a
>> first hop device for inspection. If it passes inspection, it is
>> forwarded back onto the link to its final destination. Routers are
>> allowed to forward Link-Local traffic back onto the same link
>> according to RFC4007, just not onto different links, as per RFC4291.
>>
>> Is my explanation of this in the draft unclear?
>
> no, I think it is clear.
> I think my main question is, given the specifics around 1:N deployments, what would be the use case of having a link-local scope larger than first-hop router - single subscriber?
>

So to focus on the ISP scenario, ISPs want two things (a) customers to
send more traffic so they can bill for it and (b) customers
applications having the best chance of working, so that customers
don't call the helpdesk. As long as a customer isn't using link-local
traffic to disrupt other customers (e.g, by spoofing RAs etc.), then
an ISP won't care whether inter-customer traffic is using Link-Local
addresses or GUA addresses, as long as they can bill for it.

If an ISP doesn't want to "switch on" what I've proposed, then that is
their choice. The trouble is that currently there is no way to switch
it on even if an ISP (or anybody else using a CBMA link) wants to.

> what applications would require link-local addresses for this?

I don't know.

But does it matter? At the network layer, aren't we not supposed to
care what the applications do with the packets, we just try our best
to deliver them?

On every other link type (BMA, NBMA, P2P), Link-Locals have such a
high likelihood of success of working that if an application has a
choice to use LLs verses ULAs/GUAs, the address selection RFC says
pick the Link-Locals.

This is a network layer constraint dictating what addresses an
application can use, and it doesn't signal that limitation to the
application, so if an application would gain most value from using
Link-Locals, the application now has to have extra code to cope with
LLs failing on some types of link, and then either completely failing
if they only use LLs, or fall back to using ULAs or GUAs if they're
available.

That's application development time that really should be spent on
further application development, not overcoming network layer
limitations. I think we've paid enough of that price with NAT
traversal in IPv4.

>>> in IPv6 you could easily put each node on separate subnets.
>>>
>>
>> I don't think it is always that easy. How do you do that on Wifi
>> networks? The only way I can think of is to have per-host SSIDs, and I
>> don't know how easily that could be done (attach to a shared visible
>> SSID, that then informs the host as to which (hidden) SSID it is to
>> use, ensuring 1:1 host to SSID? does such a mechanism exist?)
>
> I think there are already deployments of this.
> we also had a student that implemented a prototype, essentially treating each station on a WIFI network as having a separate P2P link between station and first-hop router/AP. that?s quite trivial to implement and solves all the problems with multicast vs unicast. you don?t need address resolution, no need for DAD and so on.
>

So perhaps that is really saying that all link types should be true
point-to-point, and there is now no place for true multi-access
link-layers and multicasts or broadcasts over them?

>> Hosts sharing the same subnet is simpler and would create less control
>> plane load than per-hosts subnets, which results in per-subnet control
>> plane state, variables and timers, and individual per-subnet RAs, due
>> to unique PIOs.
>
> our experience is the opposite. especially in a 1:N model, where you by using this model would trade dynamic state both in Ethernet bridges and in routers for configured state. You can do away with the ND cache as well of course.
>

Yes, but on high end BRASes/BNGs, control plane resources co$t a lot
more than they do when you distribute state to the more commodity
ethernet bridges's control planes.

>> This control plane load becomes a concern on BRASes/BNGs with
>> per-subscriber subnets when supporting 1000s of PPPoE sessions. The
>> TR-101 N:1 VLANs model is much better in this regard, because one
>> single multicast RA is for all devices attached to the VLAN.
>>
>>> also, if you continue with the semi-shared subnet model, do you need link-local communication between nodes? instead of advertising FE80::/10 as off-link, can?t you just block any inter-node LL traffic?
>>>
>>
>> Blocking of inter-node LL traffic is inherent in the CBMA links. But
>> that is a problem because IPv6 applications are allowed to use LLs,
>> and address selection will prefer them if there is a choice between
>> LLs and ULA or GUAs. Inter-node LL is currently broken on CBMA links
>> because of the LL on-link assumption, and that may cause applications
>> that try to use them to fail.
>
> address selection would only prefer them if you gave it a LL DA. in this case there wouldn?t be a way to give it one, right?
>

As I mentioned above, "layer 5" applications don't know about layer 3
limitations. How would an application know that it can use LLs because
it is attached to a BMA, NBMA or a P2P link, but can't use LLs because
it is attached to a CBMA link?

Is the goal to try to get applications away from having to care about
addresses and address types, and recovering from certain address types
failures in only some scenarios, rather than going the other
direction?

The alternative position I'd take is that if LLs have no chance of
working on some link types, then applications shouldn't really be
allowed to use them at all (and therefore, either a router or DHCPv6
server must always be present on the link to give hosts addresses that
the applications can use.)

Regards,
Mark.

------------------------------

Subject: Digest Footer

_______________________________________________
ipv6 mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=dzFl9aDoUDucqeiblfZyvVGb19mtE-DOE1EvbYZCUGg&s=d1zVpuzrviDdDNFIpfmM2hYk5YfxNTIDsgN3f1BnBRU&e= 

------------------------------

End of ipv6 Digest, Vol 136, Issue 30
*************************************

---

From: 神明達哉 <[email-masked]>
Date: Thu, 20 Aug 2015 13:22:09 -0700

At Thu, 20 Aug 2015 14:00:07 +0000,

> Isn't that reverse? Isn't RFC 6724 Rule 5.5 about the selection of
> the next hop to the destination D first? Once the next hop is known,
> the sender can select the right source address based on the prefix
> the next hop advertised. When sending very first packet, how can a
> sender find out which next hop to use to get to D?

Yeah, this part can be confusing.  I tried to clarify this point in my
latest suggested text:
https://mailarchive.ietf.org/arch/msg/ipv6/CbcuKOGo8cT51vlFhs6Cn7uU1Eg
Hopefully it now makes more sense and is more compatible with RFC 6724.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Aug 2015 08:45:41 +1200

(Subject header made a bit useful)
> Hopefully it now makes more sense and is more compatible with RFC 6724.

The draft describes what to to do given that a certain source address
has been chosen. RFC 6724 describes how to choose a source address. These
are logically distinct actions but if they are both performed correctly
things will work better.

    Brian

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 21 Aug 2015 18:59:34 +0000

>From: Brian E Carpenter [mailto:[email-masked]] 
>Sent: Thursday, August 20, 2015 4:46 PM
>To: 神明達哉; Mudric, Dusan (Dusan)
>Cc: [email-masked]
>Subject: RFC 6724 and draft-baker-6man-multi-homed-host
>
>>>>> For the main purpose of this draft, the most important thing is to 
>>>>> choose the right default router for a given source address, right?  
>>>>> In that sense, the more important part of Section 3 is the third 
>>>>> paragraph:
>>>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.
>> org_arch_msg_ipv6_CbcuKOGo8cT51vlFhs6Cn7uU1Eg&d=BQIFaQ&c=BFpWQw8bsuKpl
>> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=AfH2l_yohlph
>> vHs-Y653jRl9gZU09WL7jxWupPi0u-M&s=maP3fNpwiUXch5vOcknWa0Ku8iNbD-qhMLB6
>> iVpN5Gg&e= Hopefully it now makes more sense and is more compatible 
>> with RFC 6724.
>
>The draft describes what to to do given that a certain source address has been chosen. RFC 6724 describes how to choose a source address. These are logically distinct actions but if they are both performed correctly things will work better.
>
>    Brian
>
Can draft state the distinction between RFCs 6724, 4861 and the new ideas in simple terms? May be in abstract. RFC 6724 rule 5.5 selects a source address based on a router that can reach the destination. My understanding is that draft modifies RFC 4861, section 5.2 "Sending Algorithm ". If that is the case, the draft should state the new algorithm. For example, what should be in the entries of the prefix list and/or router list, and how the next hop should be determined for off-link destinations.
    Dusan

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 24 Aug 2015 18:28:57 +0000

>> Yeah, this part can be confusing.  I tried to clarify this point in 
>> my latest suggested text:
>> vHs-Y653jRl9gZU09WL7jxWupPi0u-M&s=maP3fNpwiUXch5vOcknWa0Ku8iNbD-qhMLB
>> 6 iVpN5Gg&e= Hopefully it now makes more sense and is more compatible 
>> with RFC 6724.
>
[Dusan 1]

[Dusan 2] 
Thanks for the updates: 
> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbaker-2D6man-2Dmulti-2Dhomed-2Dhost-2D02&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=IbxK_IXn_y7zFuoQD4lzFQye0gOz5f2yvE4sZbycEZ4&s=pBvsn1TWUHlCTGgjUdBiU1iNjoYD8GIQt3rBZQFL5EU&e= 

The algorithm is still not accurately defined. I can coauthor the draft with you. I suggest adding section 3.1 "Sending Algorithm" and defining differences to RFC 4861. Here is my proposal for "Sending Algorithm"

3. Reasonable expectations of the host
	   There is an interaction with Default Address Selection [RFC6724].	
	   Rule 5.5 of that specification states that the source address used when	
	   sending to a given destination address should, if possible, be chosen for	
	    a prefix known to be advertised by the first-hop router for that	
	   destination.  This draft defines rules how hosts remember which first-hop routers
                 advertised which prefixes and how to use these prefixes while sending packets.

3.1 Sending Algorithm
RFC 4861, section 5.2, defines sending algorithm. It uses a combination of the Destination Cache Entry (DCE) table, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop. The next hop can be either on-link neighbor or a first hop router. If there is no DCE table entry that matches the destination address and there is no matching destination address prefix in the Prefix List, a packet is sent to the selected first hop router. RFC 4861, section 6.3.6,  "Default Router Selection" selects the first hop router based the router reachability or a round-robin fashion. This algorithm does not guarantee the packet from a multi-homed hosts will be sent via the next hop to the destination D. This draft defines further improvements to RFC 4861 to facilitate better first hop router selection.

When a host receives RA message, RFC 4861 section 6.3.4 "Processing Received Router Advertisements" needs to add that the host should update the entry in the Default Router List with the list of prefixes the router advertised. When a prefix is removed from the Prefix List, it must be removed from the entry in the Default Router List.

When a multi-homed host is sending a packet to off-link destination, it will first select a source address. RFC 6724 SASA rule 5.5 might be used to select the source address. The packet has matching {Source_IP, Destianton_IP} pair needed to pass ISP ingress filtering. The next step is a first hoop router selection. The existing RFC 4861 "Default Router Selection" needs to be modified to use the SASA selected source address for the next hope router selection. During the default router selection the host will prefer the entry from the Default Router List which has the prefix of the selected source address. The selected next hop entry is put in the DCE table. The packet is sent over the selected first hop router. Destination ISP network ingress filtering will not discard the packet because the source address has the matching prefix for the destination subnet. Subsequent packets are sent based on the destination IPv6 address and the DCE table entry match.

Assumption of rule SASA 5.5  is that the SASA selected source address is based on an advertised prefix. If destination D is reachable over the first hop that did not advertise the address prefix, the implementation should add the destination address to the first-hop router entry in the Default Router List. This address can be used during Default Router Selection to select the first hop router for the off-link destination address.
===========================================================================================

With this algorithm, there is no need to refer to 'history' "When a host makes a successful exchange with a remote destination using a particular source address". The send algorithm does not start with a successful exchange. This assumption about successful send process is based on a random send algorithm and should not be used in the draft. The whole paragraph should be removed. The proposed algorithm above refers to the DCE entry instead. DCE table contains the history of the  first sent packet.

We also need to answer questions regarding SASA rule 5.5. The rule says to select the next-hop that will be used to send to D. It does not say how to select the next-hop. We need exact steps to make sure the first hop router is always properly selected. What are the steps to select the next-hop based on the destination IPv6 address?

How is the host network in Figure 5 of 
https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-overview/?include_text=1  going to do ingress filtering of the replies? If the host selects a source address based on Router 1 prefix and sends a packet over Routre 2,  what will happen with the reply?

Dusan

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Aug 2015 08:46:13 +1200

Dusan,

We wanted to avoid an "Updates: 4861" on this draft. If the WG wants
to do that, of course, it would be possible, but that wasn't what we
heard the WG Chairs asking us to do in Prague.

I agree that we are adding an extra step (match the source prefix)
before applying the rule in RFC4861 section 6.3.6.

>> https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-overview/?include_text=1 going to do ingress filtering of the replies? If the host selects a source address based on Router 1 prefix and s…

I'm not sure I understand the question. If Provider 2 is applying a BCP38
filter, the packet will be dropped and there is no reply. If it's not
filtering, what's the problem? Routes don't have to be symmetric.

Regards
    Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 25 Aug 2015 20:01:29 -0500

> before applying the rule in RFC4861 section 6.3.6.

I think formally updating RFC4861 section 6.3.6 to add the extra step 
make sense to me.  However, if there are arguments why that isn't a good 
idea, I'd like to hear them, I just can't think of them at this moment.

Thanks

-- 
================================================
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: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 26 Aug 2015 01:16:20 +0000

The primary argument, at least from my perspective, is that the chairs would like to take RFC 2460 and its friends to Internet Standard, and would like to change as little as they can get away with in the process. Something that changes the bits on the wire is more problematic in that endeavor than something that changes the interpretation of those bits, and something that doesn't need to change the interpretation is better yet. Where I, and I think we, are trying to strike the balance, is in reflecting the issues SADR raises without changing the semantics of information exchanged more than absolutely necessary.

To give you an idea of the range here, there are some that would like to add a routing option to the RA that specifies a source prefix, a destination prefix, and a router in some way. I'm in favor of that from a routing perspective, but that seems like a large change. If I can accomplish the same goal, at least in the general case of a default egress route, without changing the message, I'm willing to do that, and have encouraged those pushing the RA model to do so in the cases the default egress route doesn't cover. But I don't think we can deal with SADR entirely without affecting the host's choice of first hop, as we can't guarantee that routing systems will be able to deal with the issues without that.

My two yen.
________________________________________
From: ipv6 [[email-masked]] on behalf of David Farmer [[email-masked]]
Sent: Tuesday, August 25, 2015 6:01 PM
To: Brian E Carpenter; Mudric, Dusan (Dusan); 神明達哉
Cc: [email-masked]
Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host

Thanks

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

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 26 Aug 2015 18:28:24 +0000

The proposed algorithm:
- does NOT change bits on the wire. It will change only the MAC address of the outgoing packet to be able to reach the selected router while traveling to the off-link destination
- When a host receives RA message, RFC 4861 section 6.3.4 "Processing Received Router Advertisements" needs to add that the host should update the entry in the Default Router List with the list of prefixes the router advertised. When a prefix is removed from the Prefix List, it must be removed from the entry in the Default Router List. This means the data structure of the entries for Default Router list will change.
- During the default router selection the host will prefer the entry from the Default Router List which has the prefix of the selected source address. This means RFC 4861, section 6.3.6.  Default Router Selection, needs to check first for the source address prefix match with the prefixes in the Default Router list.

Thanks for feedback,
Dusan.

-----Original Message-----
From: Fred Baker (fred) [mailto:[email-masked]] 
Sent: Tuesday, August 25, 2015 9:16 PM
To: David Farmer; Brian E Carpenter; Mudric, Dusan (Dusan); 神明達哉
Cc: [email-masked]
Subject: RE: RFC 6724 and draft-baker-6man-multi-homed-host

My two yen.

> before applying the rule in RFC4861 section 6.3.6.

I think formally updating RFC4861 section 6.3.6 to add the extra step make sense to me.  However, if there are arguments why that isn't a good idea, I'd like to hear them, I just can't think of them at this moment.

Thanks

Minneapolis, MN 55414-3029  Cell: 1-612-812-9952 ================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=BQIFJg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=OhEuRmXKXVk3PA8AfhCmVR3ppGGmamfAqFEL3ajC8VQ&s=7Kn26AP0QXAuA2LcpEBciyHCcwkIoOug3wxKUFksfPM&e=
--------------------------------------------------------------------

---

From: David Farmer <[email-masked]>
Date: Wed, 26 Aug 2015 17:36:13 -0500

Ok, from a pure compatibility perspective an update to RFC4861 probably
isn't necessary. Sending traffic out a default route NOT associated
with the PIO of the source address isn't "Wrong", there is just a higher
"Risk" than sending traffic out a default route associated with the PIO
of the source address.  Even following these clarifications is NOT
guaranteed to work, it's probably more likely to work, and there is no
guarantee that NOT following these clarifications will break, it's
probably more likely to break.

However if this doesn't update RFC4861, then I'd like to see a very
strong applicability statement in this draft and clearly lay out the
Risks of not following these clarifications.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 27 Aug 2015 13:58:28 +0000

The idea is to identify use cases (a problem statement) where a wrong source address selection and router selection will cause problems. The algorithm needs to show that the these problems will be avoided.

Let's say provider 2 does not apply ingress filtering. If provider 0, where multi-homed host is, provides ingress filtering and host selects a wrong source address when sending a request, what can happen with a reply from Provider 2? It is possible that the reply in the reverse path reaches rtr1 because the destination address in the reply is based on rtr1 prefix and rtr1 advertised a default router for that prefix. If rtr1 applies ingress filtering expecting only packets from Provider1 subnet, the replies will not reach the host in Provider 0.

If the above is true, the source address based router selection by the host is important even if Provider 2 does not apply ingress filtering but Provider 0 does. If that is the case, the problem statement needs one more use case. If a right source address and a rtr2 are selected, a reply from Provider 2 will reach rtr2, not rtr1. If rtr2 enables either ingress filtering or "Source/Destination Routing" filter, the reply will reach the host.

Use case 3 can be: host selected the source address based on rtr1 prefix and sent the packet over rtr2. The Provider 2 (that does not provide ingress filtering) reply comes to rtr2 which implements "Source/Destination Routing" filter. If the destination is constrained only to the prefix rtr2 advertised to the host, the reply will not reach the host. If a right source address and a rtr2 are selected, and reply from Provider 2 reaches rtr2, "Source/Destination Routing" filter on rtr2 will not discard the replies.

   (Provider 0)
      +------+
      |          |           +------+                                                +---------
      |          |           |          |      (Network)                     /
      |          |=+===| rtr1 |====|(Provider 1)|=====|
      |          |  |       |         |                                             |
      |          |  |       +------+                                             |
      | host |  |                                                                  |    Internet
      |          |  |                                                                  |
      |          |  |    +------+                                                 |
      |          |  |    |          |      (Network)                        |
      |          |  +==| rtr2 |====|(Provider 2)|=======|
      |          |        |          |                                                  \
      +------+         +------+                                                    +----------

            Figure 5: Simple Home Network with Two CPE Routers

The same applies to figures 1 and 4.

Regards,
Dusan.

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dsarikaya-2D6man-2Dsadr-2Doverview_-3Finclude-5Ftext-3D1&d=BQICaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=1UAeb-kJWiAWRIV0ZYHhEmLtuS_V67mtRsTJkIhTBfs&s=COHtP0gVqoYwMdLlNA1iFEPLarWk-innqbVIj4wtoW4&e=  going to do ingress filtering of the replies? If the host selects a source address based on Router 1 prefix and sends a packet over Routre 2, what will happen with the reply?
>> 

I'm not sure I understand the question. If Provider 2 is applying a BCP38 filter, the packet will be dropped and there is no reply. If it's not filtering, what's the problem? Routes don't have to be symmetric.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Aug 2015 07:30:46 +1200

Hi Dusan,

On 28/08/2015 01:58, Mudric, Dusan (Dusan) wrote:
> Let's say provider 2 does not apply ingress filtering. If provider 0, where multi-homed host is, provides ingress filtering and host selects a wrong source address when sending a request, what can happen with a reply from Provider 2?

Again you are mixing source address selection and first hop selection. The draft
is about first hop selection and it's about outbound packets. Of course the
identical problem may exist at the other end for the return packets, but that
doesn't change the arguments, it just moves them to the other end.

Let's keep this draft as simple as possible.

    Brian

> It is possible that the reply in the reverse path reaches rtr1 because the destination address in the reply is based on rtr1 prefix and rtr1 advertised a default router for that prefix. If rtr1 applies ingress filtering expecting only packets from Provider1 subnet, the replies will not reach the host in Provider 0.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Aug 2015 09:35:40 +1200

> - When a host receives RA message, RFC 4861 section 6.3.4 "Processing Received Router Advertisements" needs to add that the host should update the entry in the Default Router List with the list of…

Sure. That is an implementation aspect of what the draft already says:

"A host SHOULD select
 default routers for each prefix it is assigned an address in.
 Routers that have advertised the prefix in its Router Advertisement
 message SHOULD be preferred over routers that do not advertise the
 prefix."

But, from a standards wonk point of view, that does not invalidate anything
in RFC 4861, it's an additional rule. The same is true for the sending rule;
we are adding something, not changing it.

    Brian

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 31 Aug 2015 20:47:21 +0000

Hi Brian,

> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbaker-2D6man-2Dmulti-2Dhomed-2Dhost-2D02&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJx…

Even after updates, I don't believe the draft provides a clear problem statement and a solution. It fails to recognize the importance of RFC 6724 rule 5.5 and does not define a solution in the realm of existing standards for host. The draft does not recognize the solution is a part of the sending algorithm. The draft still talks about hosts maintaining 'history' of the next hop address used. It proposes a use of result of a 'successful' connection with a destination: "When a host makes a successful exchange with a remote destination ... then the host SHOULD include the prefix in such history". This is wrong. The host should first select next hop (RFC 6724 rule 5.5), then source address (RFC 6724 rule 5.5), then send the packet (using the selected source address to find the next hop by matching the address prefix). So, nothing is sent ("exchanged with a remote destination") before the next hop router and the source address are selected.

That is why provided a full definition on 8/24/2015 (please see below). Please identify what will not work in this definition and where the source address selection and the first hop selection are mixed up.

========================================================================================================

3.1 Sending Algorithm

Assumption of rule SASA 5.5  is that the SASA selected source address is based on an advertised prefix. If destination D is reachable over the first hop that did not advertise the address prefix, the implementation should add the destination address to the first-hop router entry in the Default Router List. This address can be used during Default Router Selection to select the first hop router for the off-link destination address.
========================================================================================================

Regards,
Dusan Mudric.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, August 27, 2015 3:31 PM
To: Mudric, Dusan (Dusan); 神明達哉
Cc: [email-masked]
Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host

Hi Dusan,

> Let's say provider 2 does not apply ingress filtering. If provider 0, where multi-homed host is, provides ingress filtering and host selects a wrong source address when sending a request, what can…

Again you are mixing source address selection and first hop selection. The draft is about first hop selection and it's about outbound packets. Of course the identical problem may exist at the other end for the return packets, but that doesn't change the arguments, it just moves them to the other end.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Sep 2015 09:57:22 +1200

Dusan,

I think we're miscommunicating. Yes, someone who implements our draft will
have to augment their sending code and implement address selection rule 5.5.
But from a formal point of view that doesn't invalidate or update 4861 or 6724.

Of course, you can't create the "history" until after a successful round trip.
So there's another missing piece in the whole puzzle, which is what happens
if the first address pair that you try fails to connect. That's a much broader
question (cf the "Reachability of distributed prefixes" thread on homenet).

Regards
   Brian