Subject: RE: dual stack & IPv6 on by default

From: "Bound, Jim" <[email-masked]>
Date: Sun, 9 Mar 2003 20:59:26 -0500

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:[email-masked]] 
>Sent: Saturday, March 08, 2003 12:17 PM
>To: Ronald van der Pol
>Cc: Alain Durand; [email-masked]; [email-masked]
>Subject: Re: dual stack & IPv6 on by default 
>
>
>Ronald,
>
>Thanks for reading the draft:
>
>[email-masked] 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
>
>
>

---

From: Sebastien Roy <[email-masked]>
Date: Mon, 10 Mar 2003 10:03:00 -0500

> RAs, if nothing else were known by the end node.

Jim, I'm sorry, I don't understand what you're saying.  Can you rephrase
it?

> Are you suggesting a change to ND or to configuration of the network as

That's a really good question.  I'm not sure what would be the best way
to address this.  What we're saying in this draft is that operational
experience has shown that this part of ND could be problematic in some
circumstances.  Does ND need to be changed as a result?  Probably not.
There are no MUST's surrounding that bit of ND.  As implementors, we're
free to interpret the spec in a sane mannor.  With this draft, we're
pointing out reasons why implementors may want to be careful with that
part of ND.  There is informational value in this alone without having
to muck with the ND spec itself.

-Seb