Subject: Re: dual stack & IPv6 on by default

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

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

A possible way to approach this problem would be to make
the choice between A and AAAA be a function of whether there
is one or more IPv6 route off-link (or at least one IPv6 router sending RAs).

That way you don't have to tweak ND. But you do end up with some
having e.g. getaddrinfo() check with the kernel. I think getaddrinfo()
needs to already do some checks in order to implement the default address
selection document.

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

If you have two nodes communicating on a link and the router
dies for long enough time it seems useful to be able to
continue to communicate. Of course, the communication will fail
once the addresses become invalid but that might take a long time.

  Erik

--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Sun, 16 Mar 2003 21:26:21 -0800

> needs to already do some checks in order to implement the default 

What is the benefit of doing so versus doing the change in ndpd?

> continue to communicate.

In that case, it make sense to maintain the local subnet route
but remove the default route. Destination on the local subnet will
still be reachable, other further destination won't and we will not
try them. This can be done in ndpd.

> Of course, the communication will fail

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Mar 2003 06:48:04 +0000

> is one or more IPv6 route off-link (or at least one IPv6 router sending RAs).

Note this cuts both ways.  I've been in dual-protocol networks where IPv4
has been down and IPv6 up, so we ought to consider the general case of
availability of connectivity off-link for either protocol.

(But I do appreciate the issues here is - I think - what to do when deploying 
an IPv6 enabled host which receives AAAA responses in an IPv4-only network)

A not-uncommon enterprise deployment method for dual-protocol now is to have
a parallel IPv6 infrastructure with a separate off-site IPv6 link, such
that IPv6 is routed within the site using (for example) BSD routers with RA's
for subnets injected into the v4 VLANs (if your BSD box can VLAN-tag on a
single interface, very few cables may be needed :).  Thus the router giving 
connectivity off each subnet is different (in one case, the "smart" L2/L3 
VLAN switching equipment, in the other, PC-based routers) , and either could 
fail.  Such a deployment method is a short-term one until Cisco, Alcatel, etc
offer v6 L2/L3 functionality as exists for v4 now.

Most dual-protocol networks will probably in the medium-term fate-share IPv4 
and IPv6, so the distinction will then be somewhat moot.

Tim

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2003 14:21:11 +0100 (CET)

> What is the benefit of doing so versus doing the change in ndpd?

NDP working as designed in RFC 2461.

> try them. This can be done in ndpd.

In another message I think I pointed out that we want NDP
to work when there are no prefixes advertised with the O-bit set
(even though the prefixes are on-link).
For instance, this might be part of a potential solution to better deal with 
hidden terminal problems in wireless networks.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2003 19:38:33 +0100 (CET)

> availability of connectivity off-link for either protocol.

Good point and I agree in principle.
But the rules for detecting the lack of connectivity are likely to
be different in the IPv6 and IPv4 cases.
In IPv6 either RAs or some routing protocol provides routes to the node.
Thus the existence of (non manually configured) off-link routes indicate
the at least the first hop IPv6 routing is working.
In IPv4 in addition to dynamic schemes, the DHCP server can hand out a default 
route. But that router itself might not be working. Thus would it make sense
to be more "suspecious" about IPv4 default routes than in the IPv6 case
somehow?

  Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 17 Mar 2003 20:37:46 -0800

I'm just dropping into this thread, and maybe this idea has already come up.
But, when the DNS returns both A and AAAA records for a destination and
when there is no v6 route, why can't the source just do automatic v6-in-v4
tunneling using an address from an AAAA record as the v6dst and an address
from an A record as the v4dst? Gives you a decision tree of sorts, i.e.:

 1) when an AAAA record and a v6 route exist, use native v6. Else:
 2) when both AAAA and A records exist, but no v6 route, use
      automatic v6-in-v4 tunneling. Else:
 3) when an A record exists, use v4. Else:
 4) destination unreachable

Fred
[email-masked]

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Mar 2003 05:38:16 +0000

> from an A record as the v4dst? Gives you a decision tree of sorts, i.e.:

In principle reasonable, but many things may still cause failure, e.g.
- the tunnelling fails due to firewall blocks
- the IPv4 connectivity is down
- the A and AAAA records may point to different hosts

Tim