Re: draft-ietf-6man-multi-homed-host relies on redirects

["Fred Baker (fred)" <[e-mail]>]

> On Nov 12, 2015, at 12:05 AM, Pierre Pfister <[e-mail]> wrote:
> 
> Hello Mark,
> 
> You asked for it. ;-)
> https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01 <https://tools.ietf.org/html/draft-pfister-6man-sadr-ra-01>
Of course, right, wrong, or indifferent, the working group hasn't adopted that.

> Regards,
> - Pierre
> 
> 
>> Le 12 nov. 2015 à 08:42, Mark Smith <[e-mail] <mailto:[e-mail]>> a écrit :
>> 
>> 
>> On 12 Nov 2015 5:28 PM, "Pierre Pfister" <[e-mail] <mailto:[e-mail]>> wrote:
>> >
>> > Brian, and Fred,
>> >
>> > In the absence of redirects, or when the host does not support redirects, the packet would be routed correctly.
>> > What I am saying, is that redirection is not a viable option. As indicated, on wifi, this could end-up with a throughput
>> > divided by 4.
>> 
>> So the only way to avoid redirects and avoid double hops on the first link layer hop, is for hosts to have complete and accurate knowledge of all networks upstream of the candidate first hop routers. How would you propose to achieve that without running a fully fledged routing protocol on the hosts like OSPF or BGP in the case of the Internet?
>> 
>> Regards,
>> Mark.
>> 
>> > That situation is what makes me say it relies on redirects, as the absence of redirects create dramatic scenarios.
>> >
>> > > Le 11 nov. 2015 à 23:40, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> a écrit :
>> > >
>> > > Pierre,
>> > >
>> > >> 1. Will host actually implement this if this is only a ‘SHOULD’ (And here
>> > >> I speak about all hosts, from cheap to expensive ones).
>> > >
>> > > I would have no problem changing it to a MUST. But it remains conditional
>> > > - it's only relevant if the router happens to send a redirect. If there is
>> > > no redirect, the host can only contniue to assume that a router that announces
>> > > a prefix is capable of forwarding towards that prefix.
>> > >
>> > >> 2. Even though they do. I would like the group to understand that this
>> > >> solution *relies* on redirects to work.
>> > >
>> > > Why? If a router does not send a redirect, that means either the router is
>> > > broken, so we can do nothing, or it is happy to forward to the destination,
>> > > so everything is fine.
>> > >
>> > >   Brian
>> > >
>> > >>    I therefore ask the question again: Do we really want this solution to
>> > >> **rely** on redirects to work ?
>> > >
>> > >
>> > >
>> > > Regards
>> > >   Brian Carpenter
>> > >   http://orcid.org/0000-0001-7924-6182 <http://orcid.org/0000-0001-7924-6182>
>> > >
>> > >
>> > >
>> > > On 04/11/2015 20:33, Pierre Pfister wrote:
>> > >> Hello,
>> > >>
>> > >> Following the meeting this morning, I was asked to bring this point to the mailing list.
>> > >>
>> > >> As a reminder, there are two issues with multi-homed hosts with multiple routers on the same link and redirects.
>> > >>
>> > >> 1. If the host does redirects in the RFC4861’s way:
>> > >>    We may end-up with 'redirect ping-pongs’. (c.f. archives. I think I explained it twice already).
>> > >>
>> > >> 2. If the host does not do redirects at all:
>> > >>    We have non-optimal routing.
>> > >>
>> > >> The current document addresses this issue with the following text:
>> > >>
>> > >> ————
>> > >> 3.4.  Redirects
>> > >>
>> > >>   There is potential for adverse interaction with any off-link Redirect
>> > >>   (Redirect for a GUA destination that is not on-link) message sent by
>> > >>   a router in accordance with Section 8 of [RFC4861].  Hosts SHOULD
>> > >>   apply off-link redirects only for the specific pair of source and
>> > >>   destination addresses concerned, so the host's Destination Cache may
>> > >>   need to contain appropriate source-specific entries.
>> > >> ————
>> > >>
>> > >> This text is correct and addresses the issue, **given that** the host implements that SHOULD.
>> > >>
>> > >> Example:
>> > >> Imagine WiFi station with a host (H) and 2 routers (A and B) connected as stations.
>> > >> A and B are synchronized and thus advertise the same PIOs (HNCP, from homenet, works this way).
>> > >> H wants to send a packet. Because there is ambiguity with PIOs, it picks one randomly (let’s say A).
>> > >> Because A and B run a routing protocol, A redirects the packet to B and sends a redirect to the host.
>> > >> If the host does not do redirects, then every single packet will do H -> A -> B -> Internet.
>> > >>
>> > >> In this WiFi based setup, each sent packet is transmitted ** 4 TIMES ** on the same collision domain.
>> > >>
>> > >> That is really bad.
>> > >>
>> > >> Btw, here is the part of RFC4861 that matters too:
>> > >> ——
>> > >> 8.3 <https://tools.ietf.org/html/rfc4861#section-8.3 <https://tools.ietf.org/html/rfc4861#section-8.3>>.  Host Specification
>> > >>
>> > >>   A host receiving a valid redirect SHOULD update its Destination Cache
>> > >>   accordingly so that subsequent traffic goes to the specified target.
>> > >>   If no Destination Cache entry exists for the destination, an
>> > >>   implementation SHOULD create such an entry.
>> > >> ——
>> > >>
>> > >> In addition, RFC4861 says that routers MUST rate-limit redirects. Which means that depending on that ‘rate’,
>> > >> some messages may not results in redirects. Which means that the scenario described before may even happen
>> > >> when the host actually supports redirects… But genuinely sends packets to many different destinations.
>> > >>
>> > >> So, I have two questions:
>> > >>
>> > >> 1. Will host actually implement this if this is only a ‘SHOULD’ (And here I speak about all hosts, from cheap to expensive ones).
>> > >>
>> > >> 2. Even though they do. I would like the group to understand that this solution *relies* on redirects to work.
>> > >>    I therefore ask the question again: Do we really want this solution to **rely** on redirects to work ?
>> > >>
>> > >>
>> > >> Thanks,
>> > >>
>> > >> - Pierre
>> > >>
>> > >>
>> > >>
>> > >>> Le 4 nov. 2015 à 12:59, Fred Baker (fred) <[e-mail] <mailto:[e-mail]>> a écrit :
>> > >>>
>> > >>> Minor updates related to Jinmei's comment and Okimoto's comment.
>> > >>>
>> > >>> We are of course looking for working group review and comment.
>> > >>>
>> > >>>> Begin forwarded message:
>> > >>>>
>> > >>>> From: <[e-mail] <mailto:[e-mail]>>
>> > >>>> Subject: New Version Notification for draft-ietf-6man-multi-homed-host-02.txt
>> > >>>> Date: November 4, 2015 at 12:56:08 PM GMT+9
>> > >>>> To: "Brian E. Carpenter" <[e-mail] <mailto:[e-mail]>>, Fred Baker <[e-mail] <mailto:[e-mail]>>, Brian Carpenter <[e-mail] <mailto:[e-mail]>>
>> > >>>>
>> > >>>>
>> > >>>> A new version of I-D, draft-ietf-6man-multi-homed-host-02.txt
>> > >>>> has been successfully submitted by Fred Baker and posted to the
>> > >>>> IETF repository.
>> > >>>>
>> > >>>> Name:              draft-ietf-6man-multi-homed-host
>> > >>>> Revision:  02
>> > >>>> Title:             Routing packets from hosts in a multi-prefix network
>> > >>>> Document date:     2015-11-03
>> > >>>> Group:             6man
>> > >>>> Pages:             13
>> > >>>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-6man-multi-homed-host-02.txt <https://www.ietf.org/internet-drafts/draft-ietf-6man-multi-homed-host-02.txt>
>> > >>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/ <https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/>
>> > >>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-02 <https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-02>
>> > >>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multi-homed-host-02 <https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multi-homed-host-02>
>> > >>>>
>> > >>>> Abstract:
>> > >>>> This document describes expected IPv6 host behavior in a network that
>> > >>>> has more than one prefix, each allocated by an upstream network that
>> > >>>> implements BCP 38 ingress filtering, when the host has multiple
>> > >>>> routers to choose from.  It also applies to other scenarios such as
>> > >>>> the usage of stateful firewalls that effectively act as address-based
>> > >>>> filters.
>> > >>>>
>> > >>>> This host behavior may interact with source address selection in a
>> > >>>> given implementation, but logically follows it.  Given that the
>> > >>>> network or host is, or appears to be, multihomed with multiple
>> > >>>> provider-allocated addresses, that the host has elected to use a
>> > >>>> source address in a given prefix, and that some but not all
>> > >>>> neighboring routers are advertising that prefix in their Router
>> > >>>> Advertisement Prefix Information Options, this document specifies to
>> > >>>> which router a host should present its transmission.  It updates RFC
>> > >>>> 4861.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> 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 <http://tools.ietf.org/>.
>> > >>>>
>> > >>>> The IETF Secretariat
>> > >>>>
>> > >>>
>> > >>> --------------------------------------------------------------------
>> > >>> IETF IPv6 working group mailing list
>> > >>> [e-mail] <mailto:[e-mail]>
>> > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>> > >>> --------------------------------------------------------------------
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> --------------------------------------------------------------------
>> > >> IETF IPv6 working group mailing list
>> > >> [e-mail] <mailto:[e-mail]>
>> > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>> > >> --------------------------------------------------------------------
>> > >>
>> > >
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>> > --------------------------------------------------------------------
>