Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault]

[Alain Durand <alain@tycool.net>]

On Apr 8, 2005, at 5:41 PM, Fred Baker wrote:
> > > The on-link assumption draft will be published with  
> > > draft-ietf-ipv6-rfc2461bis, which removes that assumption.
> >
> > draft-ietf-ipv6-rfc2461bis remove the on-link assumption text but  
> > does not provide the rationale for the change.
>
> Let me play devil's advocate for a moment:  
> draft-ietf-ipv6-rfc2462bis-07.txt is right now awaiting an updated  
> draft (see  
> https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_id&dTag=11541&rfc_flag=0 for comments ). If this is the  
> primary reason for publishing this document, then maybe some text  
> (comparable to Allison's other 'discuss' questions) could simply be  
> handled there? If not, please advise specifically what additional  
> issues are covered?

I'm not sure I follow you... The change is in 2461bis, not 2462bis.

> >From my perspective, I don't have a problem sending  
> on-link-assumption back with an appropriate report and publishing it  
> with rfc2461bis. But I think I need to ask you to compare notes with  
> the authors of the other and ensure that the two drafts are entirely  
> in sync.

The relevant change in rfc2461bis is the deletion of the following  
sentence in the 2nd paragraph of section 5.2:
--> If the Default Router List is empty, the sender assumes that the  
destination is on-link.
as is suggested in the onlink asumption draft...

One think we could do is re-spin the draft to change the tense of some  
sentences
to make it more sound "this is why it was done" rather "this is how and  
why it should be done"
As the draft has expired, a new rev is needed anyway.

> v6onbydefault is rather another story from my perspective. Many end  
> systems are now coming with IPv6 on by default, and software images  
> are available from most common routers (even Linksys, which normally  
> doesn't do anything without a groundswell customer demand). For  
> routers, one also wants to design the network and appropriately  
> configure them, so they don't usually come with even IPv4 on by  
> default in a routing configuration. So if you were presenting  
> arguments for doing so, the arguments are OBE. Willing to be told  
> otherwise, but here my advice would be to take "yes" as an answer form  
> the equipment and OS folks...

Well, I used to work for an OS vendor, and my co-author still do.
Maybe it is a conservative, risk adverse one, but we were worried
that shipping our stack with v6 on by default would generate
a large number of service call, so all necessarily precautions needed
to be taken. We wrote the draft in that spirit.

Let's look at the table of content and see what is still relevant
There are essentially two parts in the document:

Things that need to be resolved in the host stacks:
2.  No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1   Problems with Default Address Selection for IPv6 . . . . .  3
	-> still an issue, but maybe this should be redirected
	     as a separate document toward an update of RFC3484.
     2.2   Neighbor Discovery's On-Link Assumption Considered
           Harmful  . . . . . . . . . . . . . . . . . . . . . . . . .  5
	-> may be obe by onlinkasuption draft
     2.3   Transport Protocol Robustness  . . . . . . . . . . . . . .  6
	-> Still an open issue, but addressed in the transport wg

Things that need to be resolved in the network:
   3.  Other Problematic Scenarios  . . . . . . . . . . . . . . . . .  6
     3.1   IPv6 Network of Smaller Scope  . . . . . . . . . . . . . .  6
       3.1.1   Alleviating the Scope Problem  . . . . . . . . . . . .  7
     3.2   Poor IPv6 Network Performance  . . . . . . . . . . . . . .  7
     3.3   Security . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.3.1   Mitigating Security Risks  . . . . . . . . . . . . . .  8
   4.  Application Robustness . . . . . . . . . . . . . . . . . . . .  9

Those last 2 sections are highlighting general deployment problems, not  
something special
for v6 on by default.

I can be convinced that if we put the issue with RFC3483 aside,
the first part is now largely obe.
Maybe we could re-focus the id on this second part if the wg thinks  
there is value here...

	- Alain.