Re: RFC 6724 and draft-baker-6man-multi-homed-host

[Brian E Carpenter <[e-mail]>]

Dusan,

We wanted to avoid an "Updates: 4861" on this draft. If the WG wants
to do that, of course, it would be possible, but that wasn't what we
heard the WG Chairs asking us to do in Prague.

I agree that we are adding an extra step (match the source prefix)
before applying the rule in RFC4861 section 6.3.6.

>> How is the host network in Figure 5 of
>> https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-overview/?include_text=1 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




On 25/08/2015 06:28, Mudric, Dusan (Dusan) wrote:
>>>>>> 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.
>>>
>>>> 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?
>>>
>>> Yeah, this part can be confusing.  I tried to clarify this point in 
>>> my latest suggested text:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.
>>> org_arch_msg_ipv6_CbcuKOGo8cT51vlFhs6Cn7uU1Eg&d=BQIFaQ&c=BFpWQw8bsuKp
>>> l 
>>> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=AfH2l_yohlp
>>> h
>>> vHs-Y653jRl9gZU09WL7jxWupPi0u-M&s=maP3fNpwiUXch5vOcknWa0Ku8iNbD-qhMLB
>>> 6 iVpN5Gg&e= Hopefully it now makes more sense and is more compatible 
>>> with RFC 6724.
>>
>> The draft describes what to to do given that a certain source address has been chosen. RFC 6724 describes how to choose a source address. These are logically distinct actions but if they are both performed correctly things will work better.
>>
>>    Brian
>>
> [Dusan 1]
> Can draft state the distinction between RFCs 6724, 4861 and the new ideas in simple terms? May be in abstract. RFC 6724 rule 5.5 selects a source address based on a router that can reach the destination. My understanding is that draft modifies RFC 4861, section 5.2 "Sending Algorithm ". If that is the case, the draft should state the new algorithm. For example, what should be in the entries of the prefix list and/or router list, and how the next hop should be determined for off-link destinations.
>     Dusan
> 
> [Dusan 2] 
> Thanks for the updates: 
>> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbaker-2D6man-2Dmulti-2Dhomed-2Dhost-2D02&d=BQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=IbxK_IXn_y7zFuoQD4lzFQye0gOz5f2yvE4sZbycEZ4&s=pBvsn1TWUHlCTGgjUdBiU1iNjoYD8GIQt3rBZQFL5EU&e= 
> 
> The algorithm is still not accurately defined. I can coauthor the draft with you. I suggest adding section 3.1 "Sending Algorithm" and defining differences to RFC 4861. Here is my proposal for "Sending Algorithm"
> 
> 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.
> ===========================================================================================
> 
> With this algorithm, there is no need to refer to 'history' "When a host makes a successful exchange with a remote destination using a particular source address". The send algorithm does not start with a successful exchange. This assumption about successful send process is based on a random send algorithm and should not be used in the draft. The whole paragraph should be removed. The proposed algorithm above refers to the DCE entry instead. DCE table contains the history of the  first sent packet.
> 
> 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?
> 
> How is the host network in Figure 5 of 
> https://datatracker.ietf.org/doc/draft-sarikaya-6man-sadr-overview/?include_text=1  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?
> 
> Dusan
>