Subject: Fwd: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Jul 2016 14:04:20 +0200

This draft has been sent for review to RTGWG and v6ops already. I
believe this document might be of interest for 6man as well
(especially Section 4).

Feedback is highly appreciated.

Thanks!

---------- Forwarded message ----------
>
> From: <[email-masked]>
> Subject: New Version Notification for draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
> Date: July 5, 2016 at 5:58:25 PM PDT
> To: Chris Bowers <[email-masked]>, Jen Linkova <[email-masked]>, "Fred Baker" <[email-masked]>, "J. Linkova" <[email-masked]>
>
>
> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
>
> Name:         draft-bowbakova-rtgwg-enterprise-pa-multihoming
> Revision:     00
> Title:                Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution
> Document date:        2016-07-05
> Group:                Individual Submission
> Pages:                44
> URL:            https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/
> Htmlized:       https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00
>
>
> Abstract:
> Connecting an enterprise site to multiple ISPs using provider-
> assigned addresses is difficult without the use of some form of
> Network Address Translation (NAT).  Much has been written on this
> topic over the last 10 to 15 years, but it still remains a problem
> without a clearly defined or widely implemented solution.  Any
> multihoming solution without NAT requires hosts at the site to have
> addresses from each ISP and to select the egress ISP by selecting a
> source address for outgoing packets.  It also requires routers at the
> site to take into account those source addresses when forwarding
> packets out towards the ISPs.
>
> This document attempts to define a complete solution to this problem.
> It covers the behavior of routers to forward traffic taking into
> account source address, and it covers the behavior of host to select
> appropriate source addresses.  It also covers any possible role that
> routers might play in providing information to hosts to help them
> select appropriate source addresses.  In the process of exploring
> potential solutions, this documents also makes explicit requirements
> for how the solution would be expected to behave from the perspective
> of an enterprise site network administrator .
>
>
>
>
> 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.
>
> The IETF Secretariat
>

-- 
SY, Jen Linkova aka Furry

---

From: David Lamparter <[email-masked]>
Date: Wed, 27 Jul 2016 21:49:23 +0200

On Thu, Jul 21, 2016 at 07:25:45PM +1200, Brian E Carpenter wrote:
> On 21/07/2016 02:34, David Lamparter wrote:
> > On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote:
> >> Please tell us ASAP if there is anything we should add to
> >> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2
> >> or thereabouts.

I believe we need to ship the following text (or something similar)
/somewhere/:

(Some points - particularly 7, 8 & 10 - might need some arguing about.
Text below is what I /believe/ to be reasonable, but I may of course
have overlooked some scenarios...)

Cheers / hoping for feedback,

-David

P.S.: Praveen - this is what I was wondering about when I asked you @
Bits'n'Bytes in Berlin.  Can you provide some insight into how Windows
implements this?

---
section: Rule 5.5 implementation considerations

Since neither RFC 4861 nor RFC 4191 detailed notes on how to "remember
which next-hops advertised which prefixes" [RFC 6724], these are listed
here:

1. Note RFC 6724 mentions "SA or SA's prefix".  This is redundant for
   SLAAC-derived addresses but needs to be considered for DHCPv6 and
   admin-configured addresses.  If a router advertises a particular
   prefix, addresses in that prefix SHOULD be preferred regardless of
   the mechanism used to configure them.

2. Neither L nor A bit in the Prefix Information Option (PIO) are
   specified anywhere to have an impact on source address selection.
   Hosts SHOULD consider all PIOs regardless of L/A bit values for the
   purposes of source address selection.

3. When using non-default routes learned from Route Information Options,
   hosts SHOULD apply the rules in the same manner, preferring source
   addresses inside prefixes advertised by the nexthop of the specific
   route used.

4. Routers MAY advertise more than one prefix (e.g. during renumbering),
   which hosts SHOULD honor up to a limit imposed by security
   considerations.

5. More than one router MAY advertise the same prefix.  In particular,
   homenet routers implementing RFCs 7695 and 7788 will exhibit this
   behaviour by default and in normal operation.  Hosts SHOULD be able
   to correctly retain identical prefixes for multiple routers, up to a
   limit imposed by security considerations.

6. A router MAY choose to include prefix information only in some of its
   RAs, for example when the sum of RA options exceeds the link's MTU.
   A host MUST NOT rely on all RAs including all information.  This also
   means a host MUST NOT implement rule 5.5 by keeping a copy of the
   last RA packet, as that packet may not have all information.

7. Entries on a router's list of advertised prefixes need to be expired
   using the prefix's (TBD: valid or preferred?) lifetime.  Hosts SHOULD
   apply the same rules regarding lifetimes as if they were configuring
   an address from that prefix.

8. A host MAY dismiss a router's list of advertised prefixes if all
   routes via that router expire.  If a host does so, it MUST ensure
   that additional routes learned from Route Information Options cause
   it to retain the list even if the default route expires (i.e. had a
   lower lifetime), or is not added to begin with.

9. Hosts MUST NOT use link-layer addresses to identify routers.  Not
   only is this information unreliable on some media (e.g. 802.11 with
   aggressive controller-based optimizations), but it also conflicts
   with (future) approaches to exploit rule 5.5 for multihoming
   scenarios.  Hosts MUST use IPv6 link-local addresses to identify
   routers for this purpose.

10. Hosts SHOULD retain prefix information even if they have no address
    inside that prefix.  Not doing so delays the application of improved
    source address selection for DHCPv6 and admin-configured addresses
    until the next receipt of a RA packet.  This can be visible to the
    user as a temporary period of failed service, or, if RAs are
    infrequent, be interpreted as entirely broken connectivity.

section: Security Considerations

Retaining additional information from router advertisements opens hosts
to another avenue of memory exhaustion attacks by malicious on-link
hosts.  Implementations MUST cap the amount of data retained.

section: Privacy Considerations

If hosts incorrectly mix prefix information across multiple interfaces,
it becomes possible for malicious on-link hosts (or routers) to
enumerate all of a host's IPv6 addresses.  Hosts therefore MUST keep
this information strictly scoped to the respective interface.

Routers generally gain a method of insight into a host's addresses.
This extends existing considerations applying to rogue RAs.  The problem
is particularly relevant on link layers where the broadcast domain is
shattered into non-transitive subdomains (e.g. Private VLANs [RFC
5517]).  Even if RAs are secured in some way, privacy is not provided
between multiple routers on the same link.

section: Acknowledgements

This text/section/... was added by David Lamparter based on
implementation observations and discussions with Lorenzo Colitti and Jen
Linkova.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jul 2016 08:19:04 +1200

David,

> I believe we need to ship the following text (or something similar)

I like what you wrote. I don't think such eminently practical information
fits very well into IETF documents but I'd be interested in other opionions.
draft-ietf-6man-multi-homed-host is in IETF LC and already on the IESG agenda,
so if we should add this sort of material Suresh had better tell us to
do so rather soon. One specific comment below...

>    purposes of source address selection.

Yes, including L=0 and A=0, as explicitly called out at the end of
https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-07#section-2.1

   Brian

---

From: Hemant Singh <[email-masked]>
Date: Wed, 27 Jul 2016 20:47:29 -0400

First, if the doc is in the IESG, so much text does not make sense to add
to the doc at this juncture.
Second, I agree with Brian that it is mostly practical information that
does not belong in an IETF RFC.
Third, it is too much text and the text has to be thoroughly reviewed by a
wide audience.  I reviewed the proposed text and see most items are not
necessary.

I have my review comments in line below preceded by "<hs>".

> which next-hops advertised which prefixes" [RFC 6724], these are listed

<hs> It is deliberate.  If a host tracks prefixes advertised by a specific
router, RFC 4861 and RFC 4191 require a change which needs to be discussed.

>    SLAAC-derived addresses

<hs> Not quite.  Also, a renumbering takes place and Prefix A is advertised
with reduced lifetime which eventually goes to zero.  Now each destination
that matches Prefix A is off-link.   Router A advertised SA Prefix A and
router B advertised SA Prefix B.  Now router selection is needed at the
host.  What SLAAC address is used for SA requires more work that a
redundant "on-link" for any SLAAC prefix.

but needs to be considered for DHCPv6 and
>    the mechanism used to configure them.

<hs>RFC4861 already covers a union of information from RA and DHCPv6 for
use by the host.  See section 6.3.4 in RFC4861 and this text: "Hosts accept
the union of all received information;"

>    purposes of source address selection.

<hs> No. If the lifetime in the PIO is zero, more work is needed to pick a
source address.

>    addresses inside prefixes advertised by the nexthop of the specific

<hs>Minor comment first.  IPv6 ND has no concept of a default route.  ND
specifies a default router for the link.   The text in this item 3 is not
needed.  When a packet is to be sent out, the host performs a longest
prefix match of the packet destination with prefixes in the Prefix List.
If a match is found, the next-hop is the packet destination.  If not, the
packet is forwarded to the default router.   If the host supports RFC 4191,
the rules are already specified in RFC 4191 for routing table.

>    which hosts SHOULD honor up to a limit imposed by security

<hs> Already covered in RFC 4861 and RFC 4862.  See section 5.5.4 in RFC
4862 and sections 6.3.5 and 12 in RFC 4861.

> <hs> Could you please provide specific text and sections from the homenet
RFCs to show why multiple routers advertise the same prefix and what is the
reason for doing so.  A topology diagram would help - maybe the diagram
exists in a homenet doc.   Then we can discuss.

>    last RA packet, as that packet may not have all information.

<hs> Section 6.3.4 of RFC 4861 already covers such details and thus Rule
5.5 of RFC 6724 is fine.

>    an address from that prefix.

<hs> It is the Preferred Lifetime.  RFC 4862 already includes the behavior
you describe above for SLAAC addresses.  DHCPv6 has address renew
mechanisms to refresh address before the address expires.   I don't see a
need to text in item 7 above.

>    lower lifetime), or is not added to begin with.

<hs> Text is not needed.  Section 6.3.5 clears specifies how to timeout
entries in the Prefix List and the Default Router List.

> <hs> If the RA includes a Source Link-layer address via the Source
Link-layer address Option (SLAO), the host is legal to use the link-layer
address.  If a link does not use Source Link-layer address, then no SLAO is
included in the RA.   How is a packet forwarded by the host to the default
router if the host does not know the link-layer address of the default
router?    More details on 802.11 optimizations are needed before the text
in item 9 is considered.

> <hs> A better model exists if the hosts only use DHCPv6.  The router sends
an RA with no PIO with the M and O bits set,  Thus hosts have all
non-link-local destinations as off-link.

> <hs> RFC 4861, in section 5.3 already says "However, a node may garbage-collect
entries prematurely if it is low on memory."

> this information strictly scoped to the respective interface.

<hs> IPv6 ND and SLAAC are protocols that work for a specific interface.
Thus this information is blatantly clear.  If host mix information, it's a
bug in the host implementation to fix.  No new text to IETF RFCs is needed.

> <hs>Again, the RA is promiscuous for a specific private VLAN domain.  It
> is clear and obvious information.
>

Hemant

---

From: Hemant Singh <[email-masked]>
Date: Thu, 28 Jul 2016 08:25:27 -0400

Brian/Fred,

Does it make sense to add a new section towards the end of the draft
below.  The new section is titled "Changes to RFC 4861" and lists specific
changes in the new section.

Thanks,

Hemant

On Wed, Jul 27, 2016 at 4:19 PM, Brian E Carpenter <
[email-masked]> wrote:

> David,
>
>
> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03
> <https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jul 2016 11:24:20 +1200

Hemant,

> changes in the new section.

We do say this in the Introduction:
"Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC
4861 will need to extend their implementations accordingly."
Is that specific enough? I think it's very hard to say more without
making assumptions about individual implementations.

(Reminder: the IETF Last Call on draft-ietf-6man-multi-homed-host expires 2016-08-04.)

Regards
    Brian

---

From: Hemant Singh <[email-masked]>
Date: Thu, 28 Jul 2016 19:31:52 -0400

Brian,

Ok, works for me - we can skip adding the new section.  Thanks to you and
Fred for working on this doc.

Hemant

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 29 Jul 2016 03:30:18 +0000

Hi Brian,

> do so rather soon. One specific comment below...

I agree with your assessment that this is closely tied to implementation 
details and does not belong here, but I am also fine if you would like to add 
some form of generic explanatory text in this regard. Feel free to discuss 
text proposals until the IETF Last Call completes. If there are no other Last 
Call comments we can handle this text addition along with any that are 
necessitated by IESG evaluation.

Thanks
Suresh