Subject: RE: dual stack & IPv6 on by default

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

Hi 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.
>
>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
>-Seb

---

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]
> Subject: Re: dual stack & IPv6 on by default 
> 
> 
> >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)

> 
> 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?
> 

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