Subject: RE: (ngtrans) isatap-03

From: Alain Durand <[email-masked]>
Date: Fri, 15 Feb 2002 09:18:37 -0800

At 8:27 AM -0800 2/15/02, Dave Thaler wrote:
>SRV records were discussed a few IETF's ago and rejected, since
>SRV records are much harder to use than A records (as one example,
>it's non-trivial to write code to do an SRV record lookup, compared
>to just calling getaddrinfo or gethostbyname).
>
>The consensus was to go for simplicity of use and administration,
>since this is just a transition mechanism.

In London, there was a discussion that wherever to use DNS A or anycast
last IETF in SLC, Fred templin hinted at using an Anycast address
and it seems there was some level on consensus for that.

So,  I understand now that you want to reserve the name ISATAP in
every DNS zone file.	 I've been looking at the IANA assignd numbe document,
I couldn't see any instance of a reserved name in the DNS tree apart the TLD.

Will this not create a (bad) precedent for anybody trying to locate a service
to ask for a reserved keyword in the DNS maps?

I'm also worried about the layer violation this introduce.
Linking DNS & routing has always been controversial,
but in this specific case, there might be a more serious problem
if DNS is done over IPv6 transport. This create a chicken and egg
problem that can only be resolved by a bootstraping phase with DNS over v4....
And even then, subsequent query for this record will still have to be made
using Ipv4 and not v6, as the v6 path may have become unreliable.

	- Alain.

--

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 15 Feb 2002 10:34:51 -0800

Alain,

I'll address one aspect of your comments below:

> and it seems there was some level on consensus for that.

While a reserved Anycast address would buy a degree of freedom, our
rationale for not specifying one is that it would take away a degree of
administrative control over the ISATAP site deployment. If we reserved
an Anycast address and prefix (e.g., 128.21.2.1/24) and implementations
hard-coded that address for the purpose of sending Router Solicitations
and validating received Router Advertisements, then the trust basis
established by the Potential Router List could be defeated.

Specifically, if a node within a site used an Anycast address for the
ISATAP router polling process but the site administrator had neither
configured an ISATAP router on the Anycast address nor set up IPv4 firewall
filtering rules to prevent the Anycast address from crossing the site's
boundary, a rogue node on the outside could impersonate an ISATAP router.
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). So, the tradeoff is flexibility vs.
security, and we decided to err on the safe side.

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.

Comments?

Fred
[email-masked]

"Fred L. Templin" wrote:
> 
> 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

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 15 Feb 2002 11:09:53 -0800

Alain,

I'll now attempt to address the other aspects of your comments, but
others may wish to add more:

Fred
[email-masked]

> to ask for a reserved keyword in the DNS maps?

Actually, we simply want to reserve the name "ISATAP" so that it will not
be used for other purposes. This will allow nodes to hard-code the name
"ISATAP" for the purpose of engaging in the router polling process specified
in the draft.

Our expectation is that site administrators will configure the name service
for their site to return the IPv4 addresses of advertising interfaces of
ISATAP routers in response to queries for the name "ISATAP"; i.e.,
configuration is under the control of the site admin. We do not explicitly
require DNS for this purpose; an alternate distributed name service (e.g. NIS)
or an entry in a static hosts file (e.g. '/etc/hosts') would serve the same
purpose.
 
> using Ipv4 and not v6, as the v6 path may have become unreliable.

I really don't think there is a problem here, but perhaps I am not fully
understanding your point. Others may be able to speak to this in more
detail. 

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 15 Feb 2002 11:40:00 -0800

Hello,

I would like to announce the following personal draft that proposes
an optional extension for ISATAP which may provide benefits for some
environments. The draft is concise and to-the-point, and the subject
matter can be grasped by a quick read of the abstract. At this time,
my purpose in making this announcement is only to seek feedback from
the community on what is being proposed. Thanks in advance for any
comments you may have.

Fred Templin
[email-masked]

  "Fast Convergence Extension for ISATAP Router Discovery",
   Fred Templin, 02/01/2002

  http://www.ietf.org/internet-drafts/draft-templin-ngtrans-isatapext-00.txt 

  This document specifies an optional extension for [ISATAP] that supports
  fast convergence (i.e, fast discovery of on-link routers). The extension
  employs a subset of the multicast mechanisms specified by [6OVER4] to
  augment the NBMA mechanisms specified by [ISATAP].

---

From: Alain Durand <[email-masked]>
Date: Fri, 15 Feb 2002 12:10:05 -0800

>or an entry in a static hosts file (e.g. '/etc/hosts') would serve the same

This is exactly what I just said....

>understanding your point. Others may be able to speak to this in more

Please explain how then how an Isatap node can do DNS resolution over 
Ipv6 transport.

	- Alain.
--

---

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

> boundary, a rogue node on the outside could impersonate an ISATAP router.

Current ISATAP spec, for the communication to be reasonably secure, 
already requires sites perform "spoofing protection" filtering at the 
edge.  Many might not do this.

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

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.

> concerned about the technicality of using an Anycast address as an

But aren't we talking about using _IPv4_ anycast?  From IPv6 perspective, 
this could still be viewed as a unicast address.

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