Re: New Version Notification for draft-hinden-ipv4flag-00.txt

[james woodyatt <[e-mail]>]

On Nov 17, 2017, at 15:31, Bob Hinden <[e-mail]> wrote:
> On Nov 18, 2017, at 2:39 AM, james woodyatt <[e-mail]> wrote:
>> On Nov 17, 2017, at 00:17, Bob Hinden <[e-mail]> wrote:
>>> 
>>> The flag is to tell the host to not use IPv4.  Once the host see the Flag=1, it should stop sending IPv4.
>> 
>> The draft is very confused about what the flag means. And both of the conflicting descriptions in the draft are in conflict with this statement. Here are the three conflicting positions (I’m wondering how many will emerge before this can be sent back to the April 1 queue).
>> 
>> — "IPv4 is Not Available on this Router"
>> 
>> — "A host that receives only RAs with the flag set to 1 should not attempt IPv4 operations, unless it subsequently receives at least one RA with the flag set to zero."
>> 
>> — "A host that receives Flag=1 should stop sending IPv4" (to what routers? on which interfaces? until what condition arises?).
>> 
>> Please send this draft back into the For Comedy Purposes Only category and leave the serious business of this topic to the SUNSET4 working group, which is actually chartered to deal with it.
>> 
> 
> That’s harsh.
> 
> I note that the relevant draft in sunset4 has been updated in 3 years, and Sunset four hasn’t meet since IETF97.  Doesn’t seem like anything will happen there.

The SUNSET4 working group still has an active charter.

> We wrote this to solve what I think is a real issue observed with the use of NAT64 on the IETF100 network.


It’s not a good solution. The issue is quite a bit more complex than jamming a new flag into the RA message will allow.

Consider the current behavior of some of the products that my employers produce, which send RA messages (lifetime=0) on their Wi-Fi interfaces to distribute PIO elements to hosts that need ULA addresses in the Nest Weave fabric space. Under this draft, each currently fielded Nest device would cancel the 4=1 flag sent by any IPv6-only default gateway. Which is a kinda silly thing to do when you’re a router between Wi-Fi™ and Thread™ and Thread™ is an IPv6-only link layer. Wouldn’t you think setting 4=1 to be a good idea in that case? Alas, it’s not. If we do that, then any dual-stack hosts on a network with an IPv4-only CE router will shut off their IPv4 activity, and they will not get any IPv6 service through us. This is probably not what anyone wants, so we would of course never ever, not in a million years, never send 4=1 in our RA messages.

Now, you might say we shouldn’t send RA messages at all (even with lifetime=0) unless we are willing to be a default router. You might say that the default router should forward our Weave fabric prefix to us from hosts on the LAN. And I would say, that sounds like a capital idea, except each and every one of the workable technical alternatives to get hosts to self-assign on-link addresses, and set host route entries for a working route to the rest of the Weave fabric behind our local router, or at least to have a reliable means of routing on home networks through the usual default route at the CE router, have all been roundly rejected by industry and at least three separate IETF working groups. We do what we can because it’s the only thing that works.

So, no… we’re not going to stop sending RA messages (lifetime=0) . And so, we’re going to step on this 4=1 bit until the end of time. In other words, this draft won’t do what it hopes to do.


--james woodyatt <[e-mail] <mailto:[e-mail]>>