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 [ipv6-bounces@ietf.org] on behalf of David Farmer [farmer@umn.edu]
Sent: Tuesday, August 25, 2015 6:01 PM
To: Brian E Carpenter; Mudric, Dusan (Dusan); 神明達哉
Cc: ipv6@ietf.org
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: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------