[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: "Mudric, Dusan (Dusan)" <dmudric () avaya ! com>
Date: 2015-09-02 14:18:47
Message-ID: 9142206A0C5BF24CB22755C8EC422E457A83F59B () AZ-US1EXMB03 ! global ! avaya ! com
[Download RAW message or body]
The improved first hope router selection algorithm increases probability that the \
packet from a multi-homed hosts will be sent via a correct first hop router to an \
off-link destination D. This algorithm still does not guarantee the packet from the \
multi-homed hosts will be sent via the first hop router to the off-link destination \
D. The selected router can further help multi-homed single-link hosts to select a \
better first hop router using Redirect message. Further investigation needs to be \
done for multi-homed multi-link hosts, where Redirect cannot be used.
This draft is based on the assumption that an off-link destination D is reachable \
while applying SASA rule 5.5. Only for the reachable destination the endpoint will be \
able to select the source address whose prefix was advertised by the first hop \
router. This has to be clearly stated in the draft. That is the key assumption. The \
draft also has to state that since the reachability is not 100% guaranteed, further \
research needs to be done to improve the first hope router selection algorithm \
(either to improve the next hop search algorithm while doing SASA rule 5.5 (e.g. \
improve host routing table updates) and/or while doing the first hop router selection \
using the ND Default Router List).
I believe with these additions and prior definitions and problem statements, the \
draft will be well rounded.
Regards,
Dusan.
-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
Sent: Tuesday, September 01, 2015 4:33 PM
To: Mudric, Dusan (Dusan); 神明達哉
Cc: ipv6@ietf.org
Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host
On 02/09/2015 07:37, Mudric, Dusan (Dusan) wrote:
> Hi Brian,
>
> SASA rule 5.5 assumes the destination D is reachable over the first hop router. I \
> already asked about the "Reachability" of the D from host perspective:
> "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?"
That is completely out of scope for this draft.
Brian
>
> The question needs to be answered. If the first hop router succeeds only in 95% to \
> provide reachability information to D, SASA rule 5.5 will return the right source \
> address for more than 95% of the requests. To have accurate outcome of SASA rule \
> 5.5, we need an extension. What else needs to be done? Is it a trace route to D: \
> www.iij-2Dii.co.jp_en_lab_resear" rel="nofollow">https://urldefense.proofpoint.com/v2/url?u=http-3A__www.iij-2Dii.co.jp_en_lab_resear> \
> chers_cristel_publications_Lutu-2Dvisibility-2DPAM2014.pdf&d=BQIFaQ&c=BFpWQw8bsuKpl1 \
> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=CTbRqwovEUcfjgq1m4ccUu_-C2WEqdArmJryEBgnTZ0&s=oC5NbBZVD3ykVE2GY-BgVcZhnYu3pBasr1NGvG6J37k&e= \
> ?
> Regards,
> Dusan.
>
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Monday, August 31, 2015 5:57 PM
> To: Mudric, Dusan (Dusan); 神明達哉
> Cc: ipv6@ietf.org
> Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host
>
> 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_rfcdiff-3Furl2" 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=BFpWQw8bsuKpl1Sgi \
> > > ZH64Q&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_do \
> > > > > c_draft-2Dsarikaya-2D6man-2Dsadr-2Doverview_-3Finclude-5Ftext-3D1&d=BQICaQ&c \
> > > > > =BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=1UAe \
> > > > > b-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
> > >
>
--------------------------------------------------------------------
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