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

["Mudric, Dusan (Dusan)" <[e-mail]>]

The proposed algorithm:
- does NOT change bits on the wire. It will change only the MAC address of the outgoing packet to be able to reach the selected router while traveling to the off-link destination
- 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. This means the data structure of the entries for Default Router list will change.
- 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. This means RFC 4861, section 6.3.6.  Default Router Selection, needs to check first for the source address prefix match with the prefixes in the Default Router list.

Thanks for feedback,
Dusan.

-----Original Message-----
From: Fred Baker (fred) [mailto:[e-mail]] 
Sent: Tuesday, August 25, 2015 9:16 PM
To: David Farmer; Brian E Carpenter; Mudric, Dusan (Dusan); 神明達哉
Cc: [e-mail]
Subject: RE: RFC 6724 and draft-baker-6man-multi-homed-host

The primary argument, at least from my perspective, is that the chairs would like to take RFC 2460 and its friends to Internet Standard, and would like to change as little as they can get away with in the process. Something that changes the bits on the wire is more problematic in that endeavor than something that changes the interpretation of those bits, and something that doesn't need to change the interpretation is better yet. Where I, and I think we, are trying to strike the balance, is in reflecting the issues SADR raises without changing the semantics of information exchanged more than absolutely necessary.

To give you an idea of the range here, there are some that would like to add a routing option to the RA that specifies a source prefix, a destination prefix, and a router in some way. I'm in favor of that from a routing perspective, but that seems like a large change. If I can accomplish the same goal, at least in the general case of a default egress route, without changing the message, I'm willing to do that, and have encouraged those pushing the RA model to do so in the cases the default egress route doesn't cover. But I don't think we can deal with SADR entirely without affecting the host's choice of first hop, as we can't guarantee that routing systems will be able to deal with the issues without that.

My two yen.
________________________________________
From: ipv6 [[e-mail]] on behalf of David Farmer [[e-mail]]
Sent: Tuesday, August 25, 2015 6:01 PM
To: Brian E Carpenter; Mudric, Dusan (Dusan); 神明達哉
Cc: [e-mail]
Subject: Re: RFC 6724 and draft-baker-6man-multi-homed-host

On 8/24/15 15:46 , Brian E Carpenter wrote:
> 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.

I think formally updating RFC4861 section 6.3.6 to add the extra step make sense to me.  However, if there are arguments why that isn't a good idea, I'd like to hear them, I just can't think of them at this moment.

Thanks

--
================================================
David Farmer               Email: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952 ================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=BQIFJg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=OhEuRmXKXVk3PA8AfhCmVR3ppGGmamfAqFEL3ajC8VQ&s=7Kn26AP0QXAuA2LcpEBciyHCcwkIoOug3wxKUFksfPM&e=
--------------------------------------------------------------------