Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-isatap-03.txt

From: [email-masked]
Date: Fri, 01 Feb 2002 07:01:31 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group of the IETF.

	Title		: Intra-Site Automatic Tunnel Addressing Protocol 
                          (ISATAP)
	Author(s)	: F. Templin et al.
	Filename	: draft-ietf-ngtrans-isatap-03.txt
	Pages		: 15
	Date		: 31-Jan-02
	
This document specifies the Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP) that connects IPv6 hosts and routers (nodes) within
IPv4 sites. ISATAP is a transition mechanism that enables incremental
deployment of IPv6 by treating the site's IPv4 infrastructure as a
Non-Broadcast Multiple Access (NBMA) link layer.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ngtrans-isatap-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ngtrans-isatap-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Feb 2002 18:05:03 +0200 (EET)

> 	Filename	: draft-ietf-ngtrans-isatap-03.txt

I read this more thoroughly for the first time on a flight.  Sorry if I'm 
bringing up dead and buried issues.

Abstract

==> add 'for IPv6'.

==> Usually in the drafts the abstract is after 'status of this memo' 
preamble, not before?

3.  Terminology

   ISATAP interface:
     a node's attachment to an ISATAP link.

==> shouldn't this be called pseudo-interface?

   ISATAP address:
     an IPv6 address with an ISATAP prefix and an ISATAP format interface
     identifier constructed as specified in section 4.

==> The IPv6 address does not have an ISATAP _prefix_ as such (the prefix 
applies to EUI64 part).

==> perhaps direct reference to 4.1?

4.1.  ISATAP Interface Identifier Construction
[...]
      0xFF         TSD is interpreted based on TSE as follows:

         	     TSE          TSD Interpretation
                   ---		------------------
                   0x00-0xFD    RESERVED for future IANA use
                   0xFE		TSD contains 24-bit EUI-48 intf id
[...]
(to the end of section 4.1)

==> this seems like a very bad case of overspecification.  _What_ use is 
this, really?  Why would anyone need EUI-48 special case for ISATAP?

4.2.  Stateless Autoconfiguration and Link-Local Addresses
    3FFE:1a05:510:1111:0:5EFE:8CAD:8108   
[...]
     3FFE:1a05:510:1111:0:5EFE:140.173.129.8

==> s/a/A/g

4.3.  ISATAP Link/Interface Configuration

   [...] ISATAP interfaces MAY be assigned one per link-
   layer address, or as a single interface for multiple link-layer
   addresses.

==> Multiple ISATAP interfaces..

   In the former case, the address of each ISATAP interface SHOULD be
   added to the Potential Routers List.

==> Add a reference to the section where PRL is first discussed.

In the latter case, the inter-
   face will accept ISATAP packets addressed to any of the IPv4 link- 
   layer addresses, but will choose one as its primary address, used for
   sourcing packets. Only this address need be represented in the Poten-
   tial Routers List.

==> why should this be supported?  AFAICS, it only makes the checks more 
difficult as the packets would not be originated from where they're sent 
to.

4.5.  Validity Checks for Received Packets

   ISATAP interfaces MUST silently discard any received packets that do 
   not satisfy ONE OF the following validity checks:

==> ONE of

==> Is this really 'not satisfy ONE and ONLY ONE', or inprecise language?
"at least one" ?

     - the link-layer (IPv4) source address is in the Potential Routers List
       (see section 5.2), i.e., previous hop is an on-link ISATAP router

==> should this address embed an ISATAP address?  (note: there are no 
checks specified in 6.1 either)

5.1.  Address Resolution

   The link-layer address option used in [DISC] is not needed. Implemen-
   tations SHOULD NOT send link-layer address options in any Neighbor   
   Discovery packets, and MUST silently ignore any such options in      
   Neighbor Discovery packets which are received.

==> "Link-layer address options SHOULD NOT be sent ..."

==> s/in Neighbor Discovery packets which are received/
      in received  Neighbor Discovery packets/

5.2.1.  Conceptual Data Structures

   ISATAP nodes use the Prefix List and Default Router List conceptual
   data structures exactly as specified in [DISC,5.1].

==> I'd say this:
"
   ISATAP nodes use the conceptual data structures Prefix List and 
   Default Router List exactly as specified in [DISC,5.1].
"

   When the node enables an ISATAP link, it initializes the PRL with  
   IPv4 addresses discovered through name service lookups for the Well- 
   Known Service name "ISATAP" (see "IANA Considerations").

==> I thought WKS was for port numbers etc. mostly....

Initialization of the PRL through
   static IPv4 address assignments and/or an alternate name for lookups
   is a supported configuration option, but the method described above
   is preferred.

==> "supported" is a bad word in an IETF draft when the behaviour isn't
described in the document.

5.2.4.  Host Specification

     MinRouterSolicitInterval
                   Minimum time between sending Router Solicitations
                   to any router. Default and suggested minimum: 15min

==> It may be just me, but this seems awfully familiar to RFC2461
"MinRtrAdvInterval"; is this enough to set this off as a host-only, NBMA 
switch?

   When the host receives a valid Router Advertisement (i.e., one that
   satisfies the validity checks in sections 4.5 and 5.2.2) it processes
   them in the same manner described in [DISC,6.3.4]. The host addition-
   ally resets the timer associated with the PRL entry that matches the 
   network-layer source address in the Router Advertisement. The timer  
   is reset to either 0.5 * (the minimum value in the router lifetime or
   valid lifetime of any on-link prefixes advertised) or MinRouterSoli- 
   citInterval; whichever is longer.

==> If something bad happens to the router, it takes on average at least
7.5 minutes to detect it -- whole this time, the packets could have ended 
up in dev/null ?

==> If a router advertises even a relatively short time (>1hr), the timer
goes to 1 hr.  If something bad happens to the router (e.g. a total crash,
renumbering), it takes on average 60/2 = 30 minutes (the DNS lookup)  to
recover?

==> that is, my worry is host-router NUD

6.1.  Host And Router Deployment Considerations

 Note that the prefixes used on the
   ISATAP and native IPv6 interfaces will be distinct.

==> How so?  Do you mean EUI64 "prefixes"?

7.  IANA considerations

   We propose that IANA adopt the interface identifier construction
   specified in section 4.1 for the existing IANA IEEE OUI registration
   ('00-00-5E').  Additionally, we request that the name "ISATAP" be
   reserved in the IANA "Protocol and Service Names" assigned numbers
   document.

==> as mentioned, the last sentence makes no sense to me.  Perhaps I'm 
missing something.

8.  Security considerations

   If IPv4 source address filtering is not correctly implemented, the
   validity checks in section 4.7 will not be effective in preventing
   IPv6 source address spoofing.

==> there is no such section.

   If filtering for ip-protocol-41 is not correctly implemented, IPv6
   source address spoofing is clearly possible, but this can be elim-
   inated if both IPv4 source address filtering, and the validity checks
   in section 4.7 are implemented.

==> this is an all-or-nothing: why not match IPv4 source with IPv6 source 
-- no need to worry about this all that much then.

==> note: any node can mask as the ISATAP router in PRL inside the site
with no IPv6 filtering if above does not hold.

==> a few additional threats:
 - the IP address of the ISATAP router can be snooped from DNS remotely
unless it's protected (e.g. with multiple views)

 - if IPv4 private addresses are used, behind-the-NAT topology is revealed 
to outsiders through IPv6 address suffixes.

-- 
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: Vladislav Yasevich <[email-masked]>
Date: Thu, 07 Feb 2002 17:32:15 -0500

> ==> shouldn't this be called pseudo-interface?

I don't think so.  This referes to the difinition of "ISATAP link" that
is located above the definition of "ISATAP interface"

> ==> The IPv6 address does not have an ISATAP _prefix_ as such (the prefix

I think this is the same as above, i.e reference to the definition of 'ISATAP
prefix' as the administratively defined prefix.

> ==> Multiple ISATAP interfaces..

Is this just your personal preference?  I think this a choice given
to the implementation.

> difficult as the packets would not be originated from where they're sent

The checks defined in Section 4.5 support this without additional difficulty.

> ==> Is this really 'not satisfy ONE and ONLY ONE', or inprecise language?

I think it's neither.  I think there are really 2 cases here. Case 1 is,
if the address is in ISATAP format, it must satisfy check #1 (on-link
verification). Case 2, is when the address is native IPv6, it must satisfy
check #2. (ISATAP router verification).

It may need to be better described in the document.

> checks specified in 6.1 either)

Not necessarily.  This would be the case of Native IPv6 to ISATAP
communication.

> ==> I thought WKS was for port numbers etc. mostly....

Addresses and port numbers.  However, the port bitmap may be 0.  The other
questions is whether WKS is what was intended (some examples use A records).

> described in the document.

How about "optional"?

> "MinRtrAdvInterval"; is this enough to set this off as a host-only, NBMA

The two variables trigger different functions and are defined for routers vs.
hosts.  

> 7.5 minutes to detect it -- whole this time, the packets could have ended

I think NUD would take care of this sooner...
>From what I understand, this timer is used to refresh router information.
However, NUD is trigered based on the ReachableTime which is not used in
the calculation of this timer.

Granted if you one have 1 ISATAP router, you will have connectivity problems
if the router goes down.  This is no different then regular IPv6.

> ==> that is, my worry is host-router NUD

See above.

> ==> How so?  Do you mean EUI64 "prefixes"?

See definiton of ISATAP prefix.  This is admistratively defined
(i.e. out of 3ffe:200:54::/48, I define 3ffe:200:54:AA::/64 to
be an "ISATAP prefix").

> ==> there is no such section.

Change to Section 4.5

> -- no need to worry about this all that much then.

This would cause problem communicating with native IPv6 nodes...

> with no IPv6 filtering if above does not hold.

I think this is where "responsible site management" comes into play. :)

> unless it's protected (e.g. with multiple views)

Or some other version of access control...

-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: Thu, 07 Feb 2002 15:15:19 -0800

Hi Pekka,

Thanks for taking the time to review the spec and comment. Please
find our responses to your comments below:

Fred Templin (for the other authors)
[email-masked]

P.S. I notice Vlad has also commented on this, and his responses look
     fairly consistent with the authors' concensus.

>    Non-Broadcast Multiple Access (NBMA) link layer.

Good point - taken for the next draft revision.

> ==> Usually in the drafts the abstract is after 'status of this memo'

Agreed - also taken.

> ==> shouldn't this be called pseudo-interface?

We are certainly open to other opinions on this. But, since we're defining
the term here (and only for use in this document) whether/not to introduce a
new term such as "pseudo-interface" seems like a matter of personal preference.
RFC 2461 sets the example for IPv6 neighbor discovery over specific link layer
documents, and it does not define "pseudo-interface" - neither does RFC 2893,
which sets the example for auto-tunnelling mechanisms. Both of these documents
are normative references for ISATAP. RFC 3056 defines "6to4 pseudo-interface",
but it is an informative reference (not normative) for ISATAP.   

> ==> perhaps direct reference to 4.1?

We also define 'ISATAP prefix', thus an ISATAP address must satisfy
both conditions (i.e., have both an ISATAP prefix and an ISATAP format
interface ID).
 
>       0xFF         TSD is interpreted based on TSE as follows:

Not needed for ISATAP, but specified to provide generic rules for [EUI-64]
interface identifier construction when the IANA-assigned OUI of '00-00-5E'
is used. This language is being proposed for adoption by IANA.
 
>      3FFE:1a05:510:1111:0:5EFE:140.173.129.8

Taken.
 
> ==> Multiple ISATAP interfaces..

We didn't quite follow this; are you suggesting alternate text?

> ==> Add a reference to the section where PRL is first discussed.

Taken.
 
> difficult as the packets would not be originated from where they're sent

This is analagous to having a single primary address and multiple "alias"
addresses assigned to an ordinary interface. The interface accepts packets
addressed to the primary address or any of the alias addresses, but always
sources packets using the primary address. This does not complicate the
validity checks in any way, and seems like a legitimate configuration
option that should not be disallowed. It MAY also be useful to keep the
Potential Routers List short. 
 
> ==> Is this really 'not satisfy ONE and ONLY ONE', or inprecise language?

"at least one" is the correct interpretation. We will work on disambiguating
the text.

> checks specified in 6.1 either)

If you mean "should the network-layer (IPv6) source address embed an ISATAP
address", the answer is no. The only requirement we are asking to be satisfied
by this check is that the previous hop is an on-link ISATAP router. The only
information we get about the previous hop is the IPv4 source address, i.e.,
the IPv6 source address comes from the true source - not the previous hop. 
 
>       in received  Neighbor Discovery packets/

Taken on both counts.
 
>    Default Router List exactly as specified in [DISC,5.1].

Taken.
 
> ==> I thought WKS was for port numbers etc. mostly....

Our terminology is loose here. We are seeking to add the name "ISATAP"
to the "Protocol and Service Names" assigned numbers document found at:

  http://www.iana.org/assignments/service-names

This is to provide a well-known name for name service lookups. We are
NOT asking that DNS WKS RR's be used for encoding IP addresses associated
with the name "ISATAP", however; when DNS is used, we expect that ordinary
"A" records will be used for this purpose. We will work on better text
for this.

> described in the document.

How does this sound:

 "Implementations MAY OPTIONALLY support initialization of the PRL through
  static IPv4 address assignments and/or an alternate name for lookups.
  But, the method described above is preferred."

> "MinRtrAdvInterval"; is this enough to set this off as a host-only, NBMA

RFC2461, sections 6.2.1 and 6.3.2, both say: "The specific variable names
are used for demonstration purposes only, and an implementation is not
required to have them...". Should we add similar text to address this
concern?

> ==> that is, my worry is host-router NUD

In section 5, we say:

   "ISATAP links SHOULD implement Redirect, Neighbor Unreachability
    Detection, and next-hop determination exactly as specified in [DISC]."

and the scenario you mention above is one intended purpose for this;
NUD would result in our avoiding the unreachable router.

> ==> How so?  Do you mean EUI64 "prefixes"?

No - the IPv6 prefixes; see again the terms "ISATAP prefix" and ISATAP
address" defined in section 3.
 
> ==> as mentioned, the last sentence makes no sense to me.  Perhaps I'm

Hopefully, the response to your related comment above will help with this.

> ==> there is no such section.

Good catch; this is now setion 4.5.
 
> -- no need to worry about this all that much then.

We only accept packets received from either a) an on-link ISATAP neighbor or
b) an on-link ISATAP router. Your check above is only useful for case a); in
case b), the IPv6 source can be any IPv6 source address and our check comes
down to looking for IPv4 source being an element of the PRL.
 
> with no IPv6 filtering if above does not hold.

I think the above statement is true regardless of the previous statement.
I think it is also true in the general case for any IPv4/IPv6 communications.
 
> unless it's protected (e.g. with multiple views)

We believe this is true if and only if all of the site's "private" DNS
RR's could also be snooped. Responsible site security management should
probably protect against this in the general case; not just for the name
"ISATAP". Whether the "ISATAP" RR's are snooped remotely through DNS, or
guessed by some other means, attacks are stopped by ip-proto-41 filtering
at the site's borders.

> to outsiders through IPv6 address suffixes.

We were aware of this, but do not sense it as a significant threat.

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 08 Feb 2002 10:28:29 -0500

Pekka

Pekka Savola wrote:
> AFAICS, there is only one router at the moment.  When NUD fails, the text
> does not seem to specify a new one should be taken from PRL?  Should PRL
> list in this case be refreshed?  Should DNS lookup be done (after all
> routers have failed, for example) ?
> 

Here is the text from 2461, Section 7.3 that might help:

>                  ...      If the neighbor is a router, however,
>   attempting to switch to another router would be appropriate.  The
>   specific recovery that takes place is covered under next-hop
>   determination; Neighbor Unreachability Detection signals the need for
>   next-hop determination by deleting a Neighbor Cache entry.

and also Section 7.3.3

>                                                  ...  If address
>   resolution fails, the entry SHOULD be deleted, so that subsequent
>   traffic to that neighbor invokes the next-hop determination procedure
>   again.  Invoking next-hop determination at this point insures that
>   alternate default routers are tried.

So as you can see, if NUD fails to an ISATAP router, another router will be
tried (if there is one).  With a single router this is no different then 
normal IPv6 and you have a single point of failure.

-vlad

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 11:13:21 +0200 (EET)

> but it is an informative reference (not normative) for ISATAP.   

This is a personal preference, I suppose; I'd just rather call only 
"physical" interfaces "interfaces".

> both conditions (i.e., have both an ISATAP prefix and an ISATAP format

Oh.. I thought ISATAP could be used on existing IPv6 infrastructure, with 
no need to set up a separate prefix for it.  Is this trivial, or should a 
note be added at the start of e.g. 6.2 ?

> is used. This language is being proposed for adoption by IANA.

Let's continue this discussion on the other thread originated by Dave.

> We didn't quite follow this; are you suggesting alternate text?

Yes, a matter of preference I guess "Multiple ISATAP interfaces [...]" 
sounded better in my ears, at least.

> Potential Routers List short. 

What I meant is that this doesn't complicate the checks only because 4.5
don't examine IPv4 addresses and compare them to IPv6.

> the IPv6 source address comes from the true source - not the previous hop. 

Ok.

>   But, the method described above is preferred."

Perhaps:

"Implementations MAY initialize the PRL [optinally] through [...]"

(or something to the effect)

> required to have them...". Should we add similar text to address this

I don't think this is necessary.

> address" defined in section 3.

A part of the misunderstanding of mine.
  
> down to looking for IPv4 source being an element of the PRL.

Yes.  But it's all the more important to get "internal" traffic right.
  
> guessed by some other means, attacks are stopped by ip-proto-41 filtering

Yes, but then IPv4 address of the router is revealed, and it might become 
more enticing to try to try to exploit the router in some fashion.

I don't think this is a huge threat, but probably worth mentioning.
 
> We were aware of this, but do not sense it as a significant threat.

Well, it's not a critical threat as such, but probably worth noting.  Too 
bad there is no workaround for this.

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 08 Feb 2002 07:41:01 -0800

Pekka,

Just a few points in follow-up:

> "physical" interfaces "interfaces".

In retrospect, it was actually more than just personal preference that
drove our decision on this. We purposefully retained as much consistency with
RFC 2461 as possible when we introduced the new terms for ISATAP. RFC 2461
defines "link" and "interface" as shown below (notice that a tunnel over IPv4
is considered an instance of a "link"): 

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IP.  Examples are Ethernets (simple
                 or bridged), PPP links, X.25, Frame Relay, or ATM
                 networks as well as internet (or higher) layer
                 "tunnels", such as tunnels over IPv4 or IPv6 itself.

   interface   - a node's attachment to a link.
 
> note be added at the start of e.g. 6.2 ?

The seperate prefix notion came into the draft at the IPv6/NGTRANS
interim meeting last spring. Prior to that, we allowed mixtures of ISATAP
and non-ISATAP addresses within the same prefix. But by imposing the
"homogeneous prefix" restriction, the draft was simplified by orders of
magnitude. We will consider whether anything more should be said in 6.2
to strengthen this. 
  
> sounded better in my ears, at least.

We'll consider this for the next draft version.

> "Implementations MAY initialize the PRL [optinally] through [...]"

Dave's message reminded me that we had previously bashed this text about and
our concensus was that the term "optionally" was just dead weight. But, your
point is valid - the draft itself doesn't "support" anything. The draft only
specifies mechanisms (via MAY/SHOULD/MUST) and leaves it up to implementations
to support them to the degree indicated by the keyword. We'll work on better
text for this. It will probably be identical to the text you suggest - minus
one extraneous word, that is!
 
> AFAICS, there is only one router at the moment.

Remember that there are two independent (but related) periodic procesess:
1) periodic name service lookups to add/remove IPv4 addresses to the PRL
and 2) periodic polling of members of the PRL via unicast Router Solicitations.

The first process populates the PRL with zero or more entries, while the
second process polls each PRL member with the side effect that received
Router Advertisements will populate the prefix/default routers conceptual
data structures exactly as specified in [DISC]. So, the upshot is that there
will be zero or more routers available in the default routers list at all
times by virtue of the polling process 2) above; i.e., one shouldn't
assume there will be exactly one router.

> When NUD fails, the text
> does not seem to specify a new one should be taken from PRL?

The new one should be taken from the default routers list, as described
above and as specified in [DISC].

> Should PRL list in this case be refreshed?  Should DNS lookup be done
> (after all routers have failed, for example) ?

You are referring to the process 1) I described above. At this time, I
don't see how an implementation could draw the logical conclusion that the
name service lookup results might have changed since the previous iteration
based solely on the fact that no routers are responding. Perhaps you mean
to ask if something different should be done via process 2)? I think the
answer to this is also no, i.e., I don't think we want to encourage nodes
to poll routers any more frequently than MinRouterSolicitInterval;
especially when routers seem unreachable via NUD.

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 08 Feb 2002 07:45:06 -0800

Pekka,

Vlad's comments are right on the money with regards to our intended
alignment with the mechanisms specified by [DISC].

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 08 Feb 2002 08:52:26 -0800

Pekka,

Pekka Savola wrote:
> > based solely on the fact that no routers are responding.
> 
> The ISATAP router(s) might have moved, in e.g. IPv4 topology: when this
> happens, it appears to me that ISATAP service will freeze (no
> reachable/known routers), unless a lot of administrative care
> (decrementing DNS lookup period in all hosts) is observed, for about
> 30minutes (half of the polling time).
> 
> An ideal algorithm should be "self-clocking" e.g. measure the validity of
> the DNS record froom TTL.  In the query, a non-cached value would have to
> be requested to make the returned value meaningful, though -- I don't
> think this is possible :-/..

This is an interesting point, and one we are certainly open to more
discussion on. (I should mention that Nathan Lutchansky also suggested
the possiblity of examining DNS RR lifetimes in an earlier private
communication.)

Our goals in the draft were to both keep things simple and keep the name
service resolution interval coarse-grained enough to limit the amount
of control traffic in the network. But, these goals need to be traded
off against the situation you describe above.

Thanks,

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 08 Feb 2002 08:52:26 -0800

Pekka,

Thanks,

Fred
[email-masked]

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 08 Feb 2002 14:24:26 -0500

Pekka

> 30minutes (half of the polling time).

You are assuming that the router renumbered during the given move.
If the deployment is done using site anycast (descibed in previouse
drafts???),
then the service interruption is avoided.

Q to Fred:
    I can not find the 'anycast' usage in the draft anymore.  What is
    droped for a particular reason?

> think this is possible :-/..

I've also considered using the TTL from DNS as a driver for the
the query timer.  It is possible to ask for a non-cached value
of the TTL by finding the zone cut and asking the authoritative
server for the zone.  The issue becomes the amound of control traffic
(addes SOA and possible NS and A/AAAA queries) and implementation complexity
(assuming A records are normally used.  Some of the complexity
is removed if something other then A records are used).

-vlad

---

From: Pekka Savola <[email-masked]>
Date: Fri, 8 Feb 2002 18:43:41 +0200 (EET)

> and 2) periodic polling of members of the PRL via unicast Router Solicitations.

Sure.
 
> assume there will be exactly one router.

Ah ok, this clarifies the issue; somehow I had a misconception about the 
"interaction" between the two.

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 08 Feb 2002 12:08:39 -0800

Vlad,

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

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 08 Feb 2002 15:55:16 -0500

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