[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host
From: Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date: 2015-08-31 21:57:22
Message-ID: 55E4CDC2.3030409 () gmail ! com
[Download RAW message or body]
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
On 01/09/2015 08:47, Mudric, Dusan (Dusan) wrote:
> Hi Brian,
>
> How did you conclude that I am mixing the source address selection with the first \
> hop selection? I joined the conversation when you "Agreed" that the draft is about \
> how to "choose the right default router for a given source address". I was the one \
> that pointed out that it is opposite and asked to clearly describe the distinction \
> and dependencies between RFCs 6724 and 4861. Some updates were made after my \
> comments:
> > Diff: www.ietf.org_" rel="nofollow">https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_> \
> > rfcdiff-3Furl2-3Ddraft-2Dbaker-2D6man-2Dmulti-2Dhomed-2Dhost-2D02&d=BQICAg&c=BFpWQ \
> > w8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=IbxK_IXn_y7zFuoQD4lzFQye0gOz5f2yvE4sZbycEZ4&s=pBvsn1TWUHlCTGgjUdBiU1iNjoYD8GIQt3rBZQFL5EU&e=
> >
>
> 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. 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. \
> ========================================================================================================
>
> Regards,
> Dusan Mudric.
>
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Thursday, August 27, 2015 3:31 PM
> To: Mudric, Dusan (Dusan); 神明達哉
> Cc: ipv6@ietf.org
> Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host
>
> Hi Dusan,
>
>
> On 28/08/2015 01:58, Mudric, Dusan (Dusan) wrote:
> > 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?
>
> 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. \
> > 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.
> >
> > > > How is the host network in Figure 5 of
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_ \
> > > > draft-2Dsarikaya-2D6man-2Dsadr-2Doverview_-3Finclude-5Ftext-3D1&d=BQICaQ&c=BFp \
> > > > WQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=1UAeb-kJWi \
> > > > AWRIV0ZYHhEmLtuS_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
> >
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic