Subject: Fwd: Re: dual stack & IPv6 on by default

From: Margaret Wasserman <[email-masked]>
Date: Sun, 09 Mar 2003 05:53:45 -0500

FYI --

A discussion on v6ops that really ought to be happening here,
since it concerns the ND RFC.

Margaret

>To: Ronald van der Pol <[email-masked]>
>cc: Alain Durand <[email-masked]>, [email-masked], [email-masked]
>From: Sebastien Roy <[email-masked]>
>Subject: Re: dual stack & IPv6 on by default
>Date: Sat, 08 Mar 2003 12:17:25 -0500
>
>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

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

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

[email-masked] said:
> The default route would always be known and PPA to send to simply from
> 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
> potential outcome.

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

---

From: Sebastien Roy <[email-masked]>
Date: Mon, 10 Mar 2003 11:31:07 -0500

[email-masked] said:
> >Ok, I agree that this would be the common case in an IPv6 only 
> >network. If a random dual stack box that has IPv6 enabled is 
> >placed in a random network out there, the common case today is 
> >that it has no IPv6 default router, and this ND rule would be 
> >problematic for it.  That's what we were trying to get across 
> >in this section of the draft.  I suppose we need to more 
> >explicitly specify in the draft what types of networks we're 
> >concerned with.
> 
> The worst case scenario would be 1 node coming up on IPv4 network with
> IPv6.  But then it would have to use transition mechanism to speak IPv6.
> Selecting the best method based on the policy of the network
> administrator I will assume here.  
> 
> Is this a fairly good synopsis of your general concern within this
> draft?

I'm not sure if I parsed what you wrote above correctly, so I can't say
for sure.  Just to make sure we're on the same page; The general concern
being addressed by this draft is that enabling IPv6 on a dual-stack node
in an IPv4 network that may or may not have IPv6 routing support might
result in side-effects that the user of that node didn't anticipate or
welcome.  Some of those are protocol related (ND, ICMPv6, TCP, etc...),
and others are administrative.

> >> 
> >> A TCP connection in SYN-SENT or SYN-RECEIVED states should abort 
> >> immediately when ND determines that the destination is 
> >unreachable, so 
> >> TCP does not incur any additional delay here.
> >
> >Is that stated somewhere (it should be)?  Should it be 
> >explicitly stated in the nodes requirements?  In practice, I 
> >don't think many TCP implementations do this correctly (or as 
> >you've described), and they should be fixed.
> 
> I believe from my knowledge most TCP implementations do this correctly.
> The above rule is very well known by TCP implementers it has nothing to
> do with ND or IPv6.  With all the specs and all the work why must we
> continue to put in specs what is already a defined process that is well
> defined.

It could very well be that the behavior is well defined to a number of
people, and implemented as such in many TCP implementations.  How it
became well defined is a mystery to me, because RFC 1122 actually
suggests (in section 4.2.3.9) to do the opposite of what makes sense in
this situation.  It says that if TCP receives an ICMP destination
unreachable code 0 (no route to destination) or 1 (host unreachable),
that it MUST NOT abort the connection.  That's in direct conflict with
what we're all agreeing is the right thing to do here (to abort the
connection if it's in SYN-SENT or SYN-RECEIVED state).

> >  Even if TCP is 
> >fixed to abort connections, there is still a 3 second delay in 
> >IP while NUD is being performed, which may or may not be 
> 
> That depends on how NUD cache was built.  Your making an implementation
> judgement not a standards judgement.  Also how one builds the NUD in the
> ND spec is a "conceptual" model not a required model just that the state
> changes are in fact supported.  For all any of us know most have figured
> this out to avoid a 3 second delay and its down to 300 nanoseconds. 

I agree that it's a conceptual model.

> 
> If you want an optimization you should suggest one so we can discuss.

My suggested optimization is that you don't assume a destination is
on-link just because you don't have a default route.

> 
> >acceptable depending on how many IPv6 destinations the 
> >application will try before trying IPv4.  
> 
> And some applications will never try IPv4 because they are not using
> IPv4 anymore for this application.  We cannot assume in the logic
> premises for this discussion that ALL applications can just use IPv4
> that is an invalid assumption I believe.  And an incorrect way to solve
> IPv6 node "perceived" problems.

True, IPv6-only applications won't have these problems.  

> 
> >I can't see this as 
> >being acceptable when a destination resolves to a few dozen 
> >IPv6 addresses, for example.
> 
> Your speaking of the route above?  Or because of multiple DNS entries?

I'm trying to say that if you're assuming that all destinations are
on-link because you don't have a default route, as a name resolves to
more IPv6 addresses, the delays associated with failed NUD on each
address are compounded.

> 
> >  An immediate ICMP destination 
> >unreachable/network unreachable from IP would be generated if 
> >it didn't assume destinations were on-link.
> 
> So you can't send to nodes not on the same link using host routes? This
> is very possible?

Absolutely, and that's exacly my point.  If you have a host route (or
any other route that covers the destination), use it.  If you don't have
a route, then the destination is unreachable.

If you don't have a route to the destination, why try to reach it
on-link just in case the destination might happen to be on-link?  Is
there a situation where this would be useful?

-Seb

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 10 Mar 2003 17:57:35 -0500

Hi Sebastien,

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

When the node hears RAs it can note the router that sent them as
implementation feature :--)

>
>> 
>> Are you suggesting a change to ND or to configuration of the network 
>> as potential outcome.
>
>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.

I agree.  

Thanks
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 10 Mar 2003 18:29:36 -0500

Hi Alain,

>
>>For edification.  I have a node on a work LAN that knows nothing of 
>>IPv6.  I download software and configure my node to be 
>capable of IPv6. 
>>I manually configure my interface to support IPv6.  I now ftp to an 
>>IPv6 address.  This is not going to work.  But I was stupid 
>to think it 
>>would?  Is this the kind of basic mistake your also worried about?
>>
>Alternate scenario:
>We ship our system so they configure IPv6 ON by default on all 
>interface. User install this machine on his v4-only network 
>and now experiment larger than usual delays to connect to his 
>favorite servers. User call customer support. This is what I 
>worried about.

Yep.  I know of large user that may require all new systems very soon
must be capable of supporting both IPv4 and IPv6.  They specifically
will require IPv6 not be enabled automaitcally.  The reason is that they
have gone far beyond Sebastien's draft of potential problems and know
not to have it enabled automatically.

It is good to document these use issues in the IETF but we need to be
responsible to make sure all sides of the coin are depicted.

I think it's a thin line where the IETF should work on operational
conditions and where they should not.  We all say we are so busy and we
have the entire problem statement area BOF in San Francisco next week.
Part of our problem is we are doing more than what we were mean't to do
in the IETF.  A lot of these issues are documented in the market but
they are not going to publicize it so some of us have to watch it get
redone here.

Regards,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 11 Mar 2003 09:55:04 -0500

> 
> So for people who want to go dual-stack in their workplace 
> yet take devices 
> to IPv4-only networks that's the problem they face.   Of 
> course you get what 
> you deserve maybe for the application writer trusting 
> presence of a DNS 
> record as an indication of connectivity.

This is for me key.  I believe in punishment, penalties, and
accountability :--) So if you do stupid things you will learn from that.

But also we cannot possibly correct every network problem like this in
IPv4 or IPv6.  Again it is not indicative of just IPv6 but IPv4 too.

Also I want to restate.  For some if IPv6 don't work then they are dead.
Fall back to IPv4 is not an option.  I know users who are going to adopt
IPv6 with the intention of phasing out IPv4 as quickly as possible and
immediately move to dominant IPv6 routing backbones on their Intranet as
a strategy.  This is also becoming more and more prevalent exponentially
too.  My guess is they see the cost and decide lets just go to IPv6 as
quick as possible and get the pain over with.

This view is now as predominant as any other for deployment and I feel
many on this list don't "get it".  This is not mean't to be negative or
a challenge merely a statement.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 12 Mar 2003 08:37:08 -0500

Yes this is better approach.
/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, March 11, 2003 4:11 PM
> To: Bound, Jim
> Cc: Steven M. Bellovin; Pekka Savola; Alain Durand; Sebastien 
> Roy; Mika Liljeberg; Ronald van der Pol; [email-masked]; 
> [email-masked]; [email-masked]
> >Mozilla is going to fix this.  Part of the problem was we 
> took so long 
> >getting rfc 2553 updated to new RFC (its in the RFC editor queue now)
> >they used Richard Stevens old program model.   This will be 
> updated to
> >getaddrinfo and I agree with Itojun.  Now as usual we await release 
> >updates :--) We also updated the API after this code base 
> that is must 
> >specify AI_MAPPED to get both v4 and v6.
> 
> 	no need for that, you can use PF_UNSPEC in 
> hints.ai_family to get both
> 	IPv4 address (as ai_family = AF_INET) and IPv6 address 
> (as ai_family
> 	= AF_INET6) and socket(2) as appropriate.
> 
> itojun
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Mar 2003 19:37:58 +0100 (CET)

> there a situation where this would be useful?

Back when the ND spec was written the idea was that if two nodes can
communicate on a link (e.g. using global addresses) it would be nice if they
could continue to communicate even if the router(s) to the link disappear.

I don't recall if there were any assumptions about the relative lifetime
of the addresses they are configured (using stateless, dhcp, or manual)
and the on-link prefixes advertised by the routers.
But given that the ND spec allows a configuration where the routers
don't advertise on-link prefixes (which causes initial packets to go through
the router and then be redirected to the on-link destination)
it would seem useful to be able to communicate after the router has
gone away.

  Erik

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Mar 2003 00:30:05 -0500

Hi Mika,

> > I think today this is the bottom line only answer.
> 
> That's too bad, because it means that the DNS resolver would 
> have do this for the whole candidate destination address 
> list. That takes time. I would much prefer do a route search only.

I agree with you and I still have reservations about source address
selection for those performance reasons.

> 
> > But your mail thread makes me wonder if we need to do more 
> and I think 
> > so.
> 
> RFC1122 clarified and corrected several small details in the 
> IPv4 specifications. I think the node requirements spec could 
> do the same for any fuzzy bits in the IPv6 specificatons.
> 
> > But it would have to be in the context of ND.  ND is a 
> requirement to 
> > use IPv6.
> 
> I agree. This is just a detail that needs to be clarified somehow.

Yes.  I can be done with new ICMP types or options.

> 
> > Feels like an edge that could be "do this if ND don't work"?
> 
> No. It's a very specific case of "how to implement the 
> following bit of next-hop determination" in a host with 
> multiple network interfaces and how it relates to RFC3484 and 
> destination address selection:
> 
> 	If the Default Router List is empty,
> 	the sender assumes that the destination is on-link.
> 
> Until there is a clear understanding, we are sticking with:
> 
> 	If the route search fails,
> 	the sender assumes the destination is unreachable.
> 
> I haven't seen comments from any other implementors. It would 
> be very interesting to hear if you have solved this and how 
> you implemented it.

Agreed.  Others need to jump in here.  I think we have a hole.

/jim
> Thanks,
> 	MikaL