RE: ipv6 Digest, Vol 136, Issue 30

["Mudric, Dusan (Dusan)" <[e-mail]>]

   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:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, August 20, 2015 5:37 AM
To: [e-mail]
Subject: ipv6 Digest, Vol 136, Issue 30

Send ipv6 mailing list submissions to
	[e-mail]

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
	[e-mail]

You can reach the person managing the list at
	[e-mail]

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
      ([e-mail])
   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
      ([e-mail])
   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: [e-mail]
To: <[e-mail]>
Cc: [e-mail]
Subject: I-D Action: draft-ietf-6man-default-iids-06.txt
Message-ID: <[e-mail]>
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 <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D Action: draft-ietf-6man-default-iids-06.txt
Message-ID: <[e-mail]>
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, [e-mail] 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
> [e-mail]
> 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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492






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

Message: 3
Date: Wed, 19 Aug 2015 14:46:12 -0700
From: [e-mail]
To: <[e-mail]>
Cc: [e-mail]
Subject: I-D Action: draft-ietf-6man-default-iids-07.txt
Message-ID: <[e-mail]>
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 <[e-mail]>
To: Mark Smith <[e-mail]>
Cc: 6man <[e-mail]>
Subject: Re: I-D Action: draft-smith-6man-link-locals-off-link-00.txt
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

Hello,

On 19 Aug, 2015, at 00:41 , Mark Smith <[e-mail]> wrote:
> On 19 August 2015 at 12:20, Brian E Carpenter
> <[e-mail]> 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 <[e-mail]>
To: ???? <[e-mail]>, "Fred Baker (fred)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: New Version Notification for
	draft-baker-6man-multi-homed-host-01.txt
Message-ID: <[e-mail]>
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)" <[e-mail]> 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
> [e-mail]
> 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 <[e-mail]>
To: Ole Troan <[e-mail]>
Cc: 6man WG <[e-mail]>
Subject: Re: New Version Notification for
	draft-smith-6man-link-locals-off-link-00.txt
Message-ID:
	<CAO42Z2zsgaOK4czwLiOfx1DhdonZQ=6VqsxME=[e-mail]>
Content-Type: text/plain; charset=UTF-8

Hi Ole,

On 19 August 2015 at 20:15, Ole Troan <[e-mail]> 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
[e-mail]
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
*************************************