Subject: Re: (ngtrans) isatap-03

From: "Fred L. Templin" <[email-masked]>
Date: Sat, 16 Feb 2002 08:15:06 -0800 (PST)

Pekka,

> On Fri, 15 Feb 2002, Fred L. Templin wrote:
> > The current specification implies that nodes will *only* begin the router
> > polling process once the site administrator has taken the specific action
> > of adding IPv4 addresses for the name "ISATAP" within the scope of the
> > site's name service (and presumably, configured filtering rules for those
> > IPv4 addresses at the site's border).
> 
> Are you suggesting a model where an implementation would have ISATAP 
> support enabled by default, and it would automatically get activated when 
> a DNS record appears?  This is IMO a bad argument; ISATAP probably should 
> be configured on/off by the user at the very least.  Some implementations 
> might choose this road, but it'd be their problem to deal with the 
> consequences.

I'm not suggesting any particular model for implementations. All I am
saying is that, once an ISATAP node has been activated, it must wait
until at least one IPv4 address appears in the Potential Routers List
before engaging in the router polling process. The IPv4 addresses may
come into the PRL through whatever means is supported by the implementation
and not in violation of the spec. (The spec currently allows name service
lookup or manual configuration.)

> Note: we could also define such a long prefix, e.g. 1.2.3.4/32 that it 
> would almost always be dropped as too specific in interdomain peerings.  
> This should kill this problem for most cases, I think.

I would certainly be interested in discussing a reasonable application
for a well-known IPv4 anycast address for ISATAP. But, would such a
restrictive prefix even be disseminated by interior routing protocols
in today's model? For example, would OSPF or IGRP advertise a /32 across
multiple hops in the majority of today's installed customer base?

> > Please note that, while we do not specify a reserved Anycast address,
> > Anycast *deployments* within a site are possible. Please see my below
> > attached note to Vlad Yasevich on this subject. Vlad suggested putting
> > the text from my note in an appendix for the ISATAP draft, but we were
> > concerned about the technicality of using an Anycast address as an
> > IPv6 source address.
> 
> But aren't we talking about using _IPv4_ anycast?  From IPv6 perspective, 
> this could still be viewed as a unicast address.

This is what I thought at first, too, but see the below language of
RFC 2373 which seems to imply that an IPv6 unicast address derived
from the ISATAP IPv4 anycast address would also be considered "anycast"
if it were assigned to multiple interfaces. Personally, I think the
language of RFC 2373 is a bit too restrictive here, but we didn't
want to go against the current standards in this case.

Fred
[email-masked]

> > > Vlad,
> > > 
> > > Vladislav Yasevich wrote:
> > > > Q to Fred:
> > > >     I can not find the 'anycast' usage in the draft anymore.  What is
> > > >     droped for a particular reason?
> > > 
> > > An anycast deployment is one possible alternative for an ISATAP site
> > > administrator, but we do not call it out specifically in the draft. In an
> > > anycast deployment, more than one ISATAP router would advertise the same
> > > IPv4 prefix (e.g. 'v4addr_any/24') into the interior routing domain and
> > > accept packets sent to the same IPv4 address (e.g. 'v4addr_any'). These
> > > routers would normally respond to Router Solicitations by sending Router
> > > Advertisements with IPv4 source address 'v4addr_any' and IPv6 source address
> > > 'FE80::5EFE:v4addr_any'. This IPv6 address would technically meet the
> > > description of an "IPv6 Anycast Address" defined by RFC 2373,
> > > section 2.6 as follows:
> > > 
> > >    "An IPv6 anycast address is an address that is assigned to more than
> > >    one interface (typically belonging to different nodes), with the
> > >    property that a packet sent to an anycast address is routed to the
> > >    "nearest" interface having that address, according to the routing
> > >    protocols' measure of distance."
> > > 
> > > But, this gets into a technicality issue with text that appears later in
> > > that same section, which says:
> > > 
> > >    "There is little experience with widespread, arbitrary use of internet
> > >    anycast addresses, and some known complications and hazards when
> > >    using them in their full generality [ANYCST].  Until more experience
> > >    has been gained and solutions agreed upon for those problems, the
> > >    following restrictions are imposed on IPv6 anycast addresses:
> > > 
> > >       o An anycast address must not be used as the source address of an
> > >         IPv6 packet."
> > > 
> > > So, we do not mention anything regarding anycast deployments since we
> > > do not want to suggest anything that would fly in the face of the existing
> > > standards. In my opinion, an anycast deployment would work just fine if
> > > configured properly and might provide significant benefits. But, it could
> > > be deemed "illegal" by the language of RFC 2373 cited above, and so we
> > > avoid suggesting it in section 6 of the ISATAP draft.
> > > 
> > > Fred
> > > [email-masked]
> > 
> > 
> > 
> > Vladislav Yasevich wrote:
> > > 
> > > Fred
> > > 
> > > Thanks for the explanation.
> > > 
> > > I think this would make an excellent appendix
> > > section just so this type of rationale doesn't
> > > get lost in the mailing list archives...
> > > As long as it doesn't hold up the draft...
> > > 
> > > -vlad
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > Vladislav Yasevich              Tel: (603) 884-1079
> > > Compaq Computer Corp.           Fax: (435) 514-6884
> > > 110 Spit Brook Rd ZK03-3/T07
> > > Nashua, NH 03062
> > 
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Pekka Savola <[email-masked]>
Date: Sat, 16 Feb 2002 18:27:17 +0200 (EET)

> lookup or manual configuration.)

Note: configuring an anycast address (v4-style) also fits in the 
description os 'manual configuration' :-)

> for a well-known IPv4 anycast address for ISATAP. 
>
>But, would such a

Yes: this is no different than putting a router loopback addresses in IGP,
which is done everywhere.

> want to go against the current standards in this case.

Interesting.

What if there is only one ISATAP router in an IGP domain ("well-known
address", not necessarily the closest address), would it still be counted
as anycast?  Further, if one used a site-local address in conjunction with
this, then it surely could be argued that it is assigned on one node only.

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 19 Feb 2002 09:48:23 -0500

Pekka

Pekka Savola wrote:
> as anycast?

I think that once you derive an IPv6 address from an ANYCAST IPv4 address,
the IPv6 address becomes anycast as well.  The fact that there is only
one router doesn't really matter because at any time another one may appear
with the same address.

Also, there is nothing that labels the address anycast (except a few well
defined anycast addresses) during communications...

> Further, if one used a site-local address in conjunction with

Why?  It may be assigned to multiple nodes within a site (i.e each department
has a site-local anycast for some peculiar service...)

-vlad

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 19 Feb 2002 09:53:30 -0800

Pekka,

I am interested in the continued discussions on the potential use of IPv4
anycast for ISATAP deployments. But, using a unique site-local address for
the Router Advertisements sent by each ISATAP router would violate the first
validity check in section 6.1.2 of RFC 2461 (i.e., "IP Source Address is a
link-local address").

Again, the current sticking point for anycast is the text in section 2.6 of
RFC 2373 that states: "Until more experience has been gained ... An anycast
address must not be used as the source address of an IPv6 packet". I view
this restriction as a technicality that MAY be out-dated and SHOULD be met
head-on (rather than danced around) if the WG wants to put more effort into
anycast for ISATAP.

Fred
[email-masked]