Subject: (ngtrans) meeting slots change for ngtrans

From: Bob Fink <[email-masked]>
Date: Wed, 28 Nov 2001 08:24:20 -0800

The final IETF agenda changed the Wednesday ngtrans slot to Friday at 9AM. 
The Thursday ngtrans slot is still at 3:30PM, so please adjust your 
schedules accordingly.

THURSDAY, December 13, 2001
1530-1730 Afternoon Sessions II
OPS     ngtrans  Next Generation Transition WG

FRIDAY, December 14, 2001
0900-1130 Morning Sessions
OPS     ngtrans  Next Generation Transition WG

We will issue an agenda by Friday. If you still have any requests for 
ngtrans items (that have published ID's and active issues discussion 
underway on the list), please let us know.

Thanks,

Bob

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 28 Nov 2001 17:31:57 -0800

Hello,

I would like to report status and solicit discussion on open issues
regarding ISATAP (draft-ietf-ngtrans-isatap-01.txt). Issues include those
raised at IETF 51, issues reported via private e-mails since IETF 51, and
issues identified by the author and his colleagues while developing an ISATAP
implementation for Linux (see also my next ngtrans mailing entitled: "Linux
ISATAP implementation".) Portions of Bob Fink's IETF 51 meeting minutes
relating to ISATAP are attached at the bottom of this message for reference.
The full set of IETF 51 NGTRANS meeting minutes are available at:

  http://www.6bone.net/ngtrans/minutes/IETF51-London.html

I am currently in the process of producing a revised version of the draft
to clear up some outstanding issues and incorporate a number of comments
received from individuals since IETF 51. I also plan to incorporate comments
resulting from any discussions on this list relative to the open issues
which appear below:

Fred Templin
[email-masked]

Open issues:
************
1) Clear definitions for "ISATAP link" and "Native link" needed:

The current draft uses the terms "on-link" and "off-link" in ways that
may lead a reader to ask "[on,off]-link with respect to WHAT?". Comments
received since IETF 51 have suggested new definitions and language to clear
up this confusion. 

2) Automatic discovery of ISATAP routers

Comments on the draft received since IETF 51 indicate that section 5 currently
intertwines the discussion of (at least) two different topics which should be
more clearly delineated. Section 5 of the draft will be re-organized to clearly
seperate the following sub-topics:

  - Discovering the IPv4 address of an ISATAP router
  - ISATAP Router Solicitation and Prefix Discovery 

3) Discovering the IPv4 address of an ISATAP router

The draft currently suggests two different methods for discovering the IPv4
address for an ISATAP router: a DNS well-known service name or an IPv4 anycast
address. A third method would include static configuration. In essence, each
method would provide the *same* information; an IPv4 address to be used as the
IPv4 destination address to which clients send unicast Router Soliciatation
messages (see ISATAP Router Discovery below). The draft should be updated to
more authoritatively specify the preferred method or methods. Items for further
consideration include the following, and I invite discussion on these:

 - Using a DNS well-known service name allows multiple IPv4 addresses in the
   DNS resource records for potential use in load balancing. Also, different
   DNS servers could provide different IPv4 addresses in name resolutions to
   provide a means for ISATAP cleints to discover the IPv4 address of the
   topologically closest ISATAP router. (This method is NOT guaranteed to
   provide the true closest ISATAP router, however.) 

 - Using an IPv4 anycast address (i.e. an IANA-registered IPv4 prefix and
   a specific address belonging to that prefix) would allow implementations
   to hard-code a single IPv4 address and provide zero-configuration operation,
   since DNS resource record configuration is avoided

 - Whatever the method for discovering the IPv4 address, the IPv4 anycast
   capability is enabled ONLY by virtue of the administrative configuration
   of one or more ISATAP routers within the site that each assign the *same*
   IPv4 address to a physical link and (presumably) each advertise the *same*
   IPv4 prefix to the site. Thus, the IPv4 anycast capability is largely
   independent of the method for discovering the IPv4 address used for anycast
   (i.e. DNS name, IANA assignment, static configuration). Therefore the method
   for discovering an IPv4 address should be clearly seperated from discussion
   of the IPv4 anycast capability in the draft. In my opinion, the IPv4 anycast
   capability should be advocated in all cases, since it allows discovery of
   the true closest ISATAP router.

Questions to the group regarding the above:

 - Do we need an IANA IPv4 prefix registration for ISATAP?
 - Can ISATAP make use of some pre-existing IANA IPv4 prefix registration?  

4) ISATAP Router Solicitation and Prefix Discovery

Since the site's IPv4 infrastructure is essentially treated as an NBMA
link, ISATAP clients must periodically poll ISATAP routers (as opposed
to ISATAP routers periodically sending beacons as described in RFC 2461
and RFC 2462.) Several aspects of this polling process must be more clearly
defined in the document. Again, discussion is invited with regards to these
items:

 - The document needs to clearly state where the mechanisms used for ISATAP
   are identical to and where they depart from those specified in RFC 2461
   and RFC 2462 

 - The polling interval should be proportional to prefix lifetimes received
   in Router Advertisements. A polling interval that is too long may allow
   prefixes to prematurely expire, while a polling interval that is too short
   could lead to traffic scaling issues. Aspects of selecting the polling
   interval must be more throroughly discussed in the document. Additionally,
   a small section discussing scaling considerations for polling interval
   selection should be added.

 - IPv6 prefix discovery methods for normal links allow multiple prefixes
   to be discovered and auto-configured on interfaces. ISATAP should be
   no different in this regard.   

5) Automatic deprecation of ISATAP interface

Section 8 of the draft currently states:

   After the node's native IPv6 address is populated in the DNS, the node
   should eventually cease sending Rtsol's to the ISATAP router and discontinue
   use of its ISATAP pseudo-interface.  In this way, ISATAP addresses will
   gradually (and automatically) disappear as IPv6 routers are widely
   deployed within sites.

It has been pointed out that there may be reasons for nodes to continue
to use an ISATAP link even after a native IPv6 link becomes available, thus
the "should" in the above section is not appropriate. A better understanding
of when it is acceptable for a node to discontinue use of its ISATAP link is
required, and discussion of this subject is invited.

6) Security considerations

The security considerations section of the draft currently states:

   Additional security issues are called out in [6TO4] and probably
   apply here as well.

This text will be replaced with text describing security considerations
specific to ISATAP. The following items are currently under consideration
and open for discussion within this forum:

 a. ISATAP IPv4 Anycast address filtering at border routers:
    Sites should configure filtering rules to disallow IPv4 packets which
    have the ISATAP IPv4 anycast address as either the v4_src or v4_dst from
    crossing the site's border routers. Otherwise, ISATAP clients may discover
    off-site ISATAP routers and/or ISATAP routers may respond to Router
    Solicitations from off-site clients

 b. Source address spoofing checks:
    For packets received on an ISATAP link, receivers should verify that the
    source address in the encapsulating IPv4 header is that of a node that is
    on-link with respect to the receiver's ISATAP interface. On-link nodes
    include other ISATAP nodes and any ISATAP router(s) with which the receiver
    has affiliated via ISATAP Router Solicitation and Prefix Discovery.

    In the case of packets originating from other ISATAP nodes that are on-link
    with the receiver's ISATAP interface, the IPv6 source address must be in
    ISATAP format (since the source is also using ISATAP), and the IPv4 address
    embedded in the ISATAP address must match the IPv4 source address in the
    encapsulating IPv4 header.

    In the case of packets originating from an on-link ISATAP router, the
    source address in the encapsulating IPv4 header must be that of an on-link
    ISATAP router, and the IPv6 source address may be any IPv6 globally
    aggregatable unicast. The source address of an on-link ISATAP router
    is available in the unicast Router Advertisements sent by the router
    and may be cached for subsequent source address spoofing checks.

    Similar considerations for source address spoofing were presented in a
    thread of discussion initiated by Pekka Savola on 08/28/01 on the NGTRANS
    mailing list entitled: "practical 6to4 security rulesets". This thread
    indicated the possibility of a draft discussing security considerations.
    Such a draft could provide an appropriate venue for more detailed discussion
    of ISATAP security rulesets as well.   

 c. Receiving link-local packets on ISATAP links:
    ISATAP treats the site's entire IPv4 infrastructure as an NBMA link.
    The draft currently specified link-local address autoconfiguration for
    the purpose of ISATAP router solicitation and prefix discovery only.
    Questions:

      - Should link-local addressing be expanded to allow for peer-peer
        communications between nodes that share and ISATAP link?

      - If so, are any filtering rules required at the site's border
        routers to disallow link-local ISATAP packets coming from
        off-site?

*** end of open issues ***

ISATAP IETF 51 meeting minutes:
*******************************
===
ISATAP Issues - Fred Templin
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/isatap.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/isatap.pdf>

Fred gave a brief overview of ISATAP, then listed the changes in ISATAP since IETF-50 (that were
reported at the Interim in Seattle).

• Name changed to ISATAP
• Added "Terminology" section
• Require ISATAP/non-ISATAP addresses use different /64 prefixes  simplifies sending rules
• Changed u/l bit in EUI-64 interface ID to indicate LOCAL scope

He then describe developments since the interim meeting:

• Linux implementation by Nathan Lutchansky:
 works with all kernel versions 2.2.16  2.4.6 (with/without USAGI)
 testing with stateful configuration complete
 multiple interface support (anticipated configuration scenario for NAT)
 code for stateless auto-configuration complete; testing begins after IETF51
 Stay tuned for code release announcements (TBD with Nathan)

Fred concluded with open issues since the interim meeting:

• When to deprecate ISATAP address?
 Old answer: when native IPv6 Rtadv's heard
 New answer: when native Rtadv's heard AND ISATAP interface usage drops below some threshold
 Not conclusive; more study needed

• Will ISATAP addresses be preferred over native IPv6 addresses by longest prefix-match?
 No  destination ordering will fix this (already addressed in source/destination selection draft)

• Will ISATAP present any new security issues? (question from private e-mail)
 IPv6 source address spoofing seems like biggest issue
 Nearly finished enumerating cases; spoofing easy to detect in all cases examined thus far
 Claim: ISATAP secure IFF site's IPv4 network secure
 Will send analysis to mailing list when complete

• Current draft expires 17 November 2001; new draft coming soon

Steve D asked what supporting multiple i/f means. Fred said two virtual i/f might be used, i.e., two
locales in one site.

Alain asked why use it across two domains. Fred said you don't use on public address side, rather
when NATs involved.

Christian noted that it is used for partially converted sites where you don't use 6to4.

Brian Zill asked if Nathan's Linux version inter-operates w/Windows yet. Fred said he had not tried
that yet.

===
ISATAP Router Discovery - Dave Thaler
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-01.txt>

SLIDES:
<http://www.6bone.net/ngtrans/IETF-51-London/isatap-rtrdisc.ppt>
<http://www.6bone.net/ngtrans/IETF-51-London/isatap-rtrdisc.pdf>

Problem Summary
• ISATAP makes IPv4 site look like one NBMA link
• Normal router discovery relies on multicast
• Observation:
 Once you know the address of a router, you can unicast an RS and get a unicast RA
• So how do you discover the address of a router?

Robustness of RA's
• Normally RAs are periodically multicast
• If no RAs known (e.g., routers down)
 Send RSs at low frequency, say 15 mins
 Tradeoff between overhead and timeliness
 Should be a temporary condition
• If RA known
 Send RS after half of lowest lifetime in RA, to a minimum of the low frequency value above
 Minimum intended to prevent overhead during renumbering

Several choices were briefly covered with pros and cons: SLP, DHCPv4, well-known host name, SRV
record lookup, well-known IPv4 anycast address, and hybrid
approaches.

Steve Deering queried that if RA is just one example of mcast, and given that we need to support
NBMA links, why is RA specially handled? Dave responded
that we need to know router ahead of time.
Steve asked again, but why special case RA? Dave noted that it is stateless.

Someone asked if he had onsidered using MARS. Dave replied yes, but that it is too complex and we
only need something until native v6 connectivity occurs,
not another special (and costly) service

Alain asked about the randomization time choice? Dave replied he needs to add it (and it will be 15
mins).

Alain stated that if using well known router name, he doesn't like unqualified (short) names as
going thru resolver it might end up outside of domain, and
is vulnerable to DoS attacks.

Fred noted that one could use different DNS responses to establish locality.

Someone asked if anycast is in use. Dave noted it is widely used in v4 today. It's just a host route
Tony Hain noted.

Dave asked if there is a preference for a given solution:

Jim B, liked anycast but disagreed that v4 anycast is in wide use, and needs to be tested very
thoroughly for v6 before it is specified/used.

Alain noted that as ISATAP is a transition mechanism, it is temporary, thus easy to do is best, and
not a hybrid; he wants to choose just one simple to
implement approach.

Dave thinks the well known host name is easiest. Alain thinks anycast is as easy. Dave agreed.

Erik Nordmark asked if we want to discover one or more routers. Dave replied that this is something
to think about.

Tony cutoff the question queue due to time. He noted that the topic should be taken to the list. He
encouraged everyone to actively participate in this
discussion online.

---

From: Bob Fink <[email-masked]>
Date: Wed, 28 Nov 2001 18:09:20 -0800

Fred,

Thanks for outlining the issues for ISATAP. As such it is a good model for 
how we should proceed with business in ngtrans, i.e., getting the 
discussion going on the mail list before the IETF.

We will certainly be prepared to have ISATAP on the Salt Lake City agenda 
to cover issues raised and not resolved here on the list.

Thanks,

Bob

===