Re: Situation with draft-ietf-v6ops-v6onbydefault-03.txt

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 18 Nov 2004, Alain Durand wrote:
> Thank you for starting this thread. Please note that there is also a 
> companion draft, draft-ietf-v6ops-onlinkassumption-02.txt that 
> provides that rationale for the change in RFC2461 about on-link 
> assumption. What should we do about this draft?
> 	- publish it as Info RFC to document the rationale for the change in 
> the update of RFC2461?
> 	- same thing, but publish it simultaneously as 2461bis?
> 	- let it expire has it has served its purpose.

It's in the similar state as this document; the second seems to make 
most sense (if it's not merged back to v6onbydefault), as RFC2461(bis) 
does not document the justification for the on-link assumption or its 
removal, and I think it'd be useful to have a document to show to 
people who would come up and ask why this is done.

> There is another aspect, which is what to publish in the DNS, and 
> this is where there is overlap with the draft in DNSop "don't 
> publish unreachable". Essentially, publishing IPv6 addresses in the 
> global DNS when one does not have global IPv6 connectivity is no 
> different than publishing IPv4 RFC1918 type addresses...

Agree.  This was a tricky document with no clear progress at dnsop 
meeting.  Someone should take it up, and document the issues with 
general unreachable address publication, as well as tradeoffs with ULA 
or similar addresses in the DNS.

> About default address, there is an issue for apps that are using UDP 
> and are (miss?)configured with an unreachable literal IPv6 address. 
> This is typically the case for a DNS stub-resolver that is 
> configured with a list of literal addresses. We had to introduce an 
> extra rule to take care of that.

Could you elaborate a bit what you mean by that?

> If you are confident that progress can be made quickly on all those 
> fronts, it may be worth holding back the publication of the draft 
> until resolution of those issues, however, i have to admit that I'm 
> a bit pessimistic...

The difficult part is being able to make progress with the TCP 
modification.  Within a couple of weeks, I believe there will be 
better knowledge how it turns out.  If you care, you could check the 
tcpm WG archives for the (long) thread, and see if you have something 
to contribute.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings