RE: dual stack & IPv6 on by default

["Bound, Jim" <Jim.Bound@hp.com>]

Sebastien,

The default route would always be known and PPA to send to simply from
RAs, if nothing else were known by the end node.

Are you suggesting a change to ND or to configuration of the network as
potential outcome.

/jim

 


>-----Original Message-----
>From: Sebastien Roy [mailto:Sebastien.Roy@sun.com] 
>Sent: Saturday, March 08, 2003 12:17 PM
>To: Ronald van der Pol
>Cc: Alain Durand; v6ops@ops.ietf.org; jim.Paugh@sun.com
>Subject: Re: dual stack & IPv6 on by default 
>
>
>Ronald,
>
>Thanks for reading the draft:
>
>Ronald.vanderPol@rvdp.org said:
>> <cite> 2.  No IPv6 Router
>> 
>>    Neighbor Discovery's [1] conceptual sending algorithm 
>dictates that
>>    when sending a packet to a destination, if a host's default router
>>    list is empty, then the host assumes that the destination is 
>> on-link. </cite>
>> 
>> Hmm, that sounds reasonable in an IPv6-only environment, but 
>not in a 
>> dual stack environment. A good example why this document is useful.
>
>I don't think I see how this would be reasonable even in an 
>IPv6-only environment.  Let's assume there are billions of 
>IPv6 devices out there. If you have no route (and I do think 
>that at the very least the ND spec should say route instead of 
>default route in this case) to one of those billions of 
>devices, what are the odds that it happens to reside on your 
>link?  This bit of ND is an optimization for a very rare case 
>at the expense of very a common case (you actually can't reach 
>the destination).  Quickly notifying the application that 
>there's no route to the destination so that the user can 
>correctly configure routes (on-link or off) seems better than 
>sitting there for minutes while TCP times out the larval connection.
>
>> <cite>
>> 4.  Poor IPv6 Network Performance
>> </cite>
>> 
>> Is this different from IPv4-only networks? In such networks 
>there can 
>> also be different paths and the path with the lowest cost 
>can have the 
>> highest packet loss.
>
>Right, it's no different from an IPv4 or IPv6 only scenario 
>where the first destination picked for a connection is 
>reachable but has poor connectivity.  One general solution to 
>this problem could be to actually connect to all destinations 
>in parallel, somehow determine which one has the best 
>connectivity, and close all of the other ones. I've been told 
>that this kind of approach has been discussed in a few context 
>at the IETF.
>
>> 
>> <cite>
>> 4.1.  Dealing with Poor IPv6 Network Performance
>> 
>> Not much can be done in this case other than configure each node to 
>> prefer IPv4 destinations over IPv6. </cite>
>> 
>> A lot can be done, the network should be fixed :-) I think you mean 
>> the end host can not do much.
>
>Right, we should be more clear.
>
>> Preferring IPv4 over IPv6 could be one
>> solution. Another could be disabling IPv6. That may be 
>clearer to the 
>> end user. It basically says: don't enable IPv6 unless you 
>are sure you 
>> have good IPv6 connectivity (or know what you are doing).
>
>Thanks for your input,
>-Seb
>
>
>