Subject: (ngtrans) INPUT: draft-ietf-ngtrans-6to4-02.txt

From: Jim Bound <[email-masked]>
Date: Mon, 26 Jul 1999 10:26:02 -0400

Adding the "relay routers" has made this more complex.  I think now we
need pictures for this depicting the issue and solutions.  The text for
Section for 5.2 is now unclear and not cohesive.  This needs to be
fixed.  Details below.

>1. Introduction
>
>   This memo specifies an optional mechanism for assigning a unique IPv6
>  address prefix to any site that currently has at least one globally
>   unique IPv4 address, and describes scenarios for using such a prefix
>  during the co-existence phase of IPv4 to IPv6 transition. Note that
>   these scenarios are only part of the total picture of transition to
>   IPv6, in addition to the mechanisms in [RFC 1933].

I think the introduction should state the other works in progress in
NGTRANS in addition to RFC 1933.

>5.1 Simple scenario - all sites work the same (section text)

>   By definition, each site has an IPv6 prefix in the format defined in
>  Section 2. It will therefore create DNS records for these addresses.
>   For example, site A which owns IPv4 address 192.1.2.3 will create DNS
>  records with the IPv6 prefix {FP=001,TLA=TLA624,NLA=192.1.2.3}/48.
>   Site B which owns address 9.254.253.252 will create DNS records with
>  the IPv6 prefix {FP=001,TLA=TLA624,NLA=9.254.253.252}/48.

This is fine IMO.  But I want to point out that if this spec does not
have to get into the anals of AAAA records vs A6 records then no other
specs should have to do this unless they are altering the DNS records,
etc.  I am making a point here to the NGTRANS chairs.  We need
consistency where there is a requirement to discuss the deetails of AAAA
records vs A6 records.  Most cases as in this tools draft and other
tools draft it is uncessary to get into these details.  If the chairs or
WG disagree lets have that discussion now.

>   When an IPv6 host on site B queries the DNS entry for a host on site
>  A, the DNS returns an address with the prefix
>   {FP=001,TLA=TLA624,NLA=192.1.2.3}/48 and whatever SLA and Interface
>   ID applies.  The converse applies when a host on site A queries the
>   DNS for a host on site B. IPv6 packets are formed and transmitted in
>  the normal way within both sites.

The above is a name to address look up as I read it.  Realize that many
applications store the address for later use to avoid the look up; I
don't think 6to4 cares but do the authors care?

>   The only change to standard IPv6 routing is that the border router on
>  each 6to4 site MUST include the sending rule:
>
>        if the destination address of an IPv6 packet is
>          {FP=001,TLA=TLA624}/16
>          then
>              if the NLA field is an IPv4 address assigned to this site
>               then queue the packet for local IPv6 forwarding
>                else encapsulate the packet in IPv4 as in Section 3
>                     with destination address set to the NLA value V4ADDR;
>                     queue the packet for IPv4 forwarding.

The above algorithm is correct but after the first condition is true;
The 6to4 router will have to forward the packet back into the sites
6NET.  Do you want to point to the diswcussion for when that takes place
so implementors can define this.  Had you not put the relay router stuff
in here I would not request this as I think all of that is overkill and
routing location/dependency is part of IPv6.  But someone has made you
discuss it; so it should have a pointer to that discussion after the
algorithm must forward the packet back into the sites 6NET.

>   The sites are not required run an IPv6 unicast routing protocol among
>  themselves in a pure 6to4 scenario.

I don't see this simply because of the first condition test above, and
the "THEN" statement following, it may be all are default routes but 
I can't see not needing an IPv6 unicast protocol.  Here is a picture for
discussion.

                            -------------
                            6to4 Router A (where V4ADDR = 16.17.2.1
                            --------------
                           /              \
               -------------             --------------
               Site Router B             Site Router C
               -------------             ---------------
                    |                          |
               ----------------          ----------------
               Host D on link B          Host E on link C
              FP=001                     FP=001
              TLA=TLA264                 TLA=TLA264
              NLA=16.17.2.1              NLA=16.17.2.1
              SLA=X'0B'                  SLA=X'0C'
              EUI=X'ABDB'                EUI=X'ACEC'
              -----------------          -----------------

Based on the statements in the algroithm if 6to4 router A gets a packet
with FP=001 AND TLA=TLA264 AND NLA=16.17.2.1 then:            
     "then queue the packet for local IPv6 forwarding"
AND if the Dst SLA=X'0B" (from Host E on link C) then the packet has to be 
forwarded to Site router B to get to Host D on link B.
How are you proposing it get to Host D without unicast routing?

>   It is RECOMMENDED that in any case each site should use only one IPv4
>  address per 6to4 router, and that should be the address assigned to
>   the external interface of the 6to4 router.  Single-homed sites
>   therefore SHOULD use only one IPv4 address for 6to4 routing.  Multi-
>   homed sites are discused in section 5.3. Note that the IPv4 interface
>  that is carrying the 6to4 traffic is logically equivalent to an IPv6
>   interface, and is referred to below as a pseudo-interface.

Question on the last sentence.  Can you define what you actually mean by
"pseudo-interface" in the front of the document (this also needs to be
done for 6over4 and Compaq will be sending any input soon on this RFC 
2529 as it is getting a full engineering review by IPv6 implementation
experts and Multicast implementors).  I assume you are not requiring
that an implementation must use a pseudo-interface, but then we may not
agree on what that means technically or from a net mgmt perspective and
why it needs to be defined.  Its not defined in anyother IPv6 spec I am
aware of either.

>   Because of the lack of configuration, and the distributed deployment
>  model, there are believed to be no particular scaling issues with the
>  pure 6to4 mechanism.

Define why you used the adjective "pure" 6to4 mechanism?  Is there an
impure one?  I do believe enough tunneling of 6to4 packets can add to
the performance costs of forwarding the packets, and I have seen
alorigthm condition tests affect performance on benchmarks but I will
defer to Scott Bradner on the issue of test and then encapsulate and
likewise for decapsulation in "routers" if Scott can comment?

Also anytime tunneling is used it creates a net mgmt issue.  Also any
IPv6 Tool or Mechanism adds to the mgmt interfaces for a user and adds
yet another thing operators must be aware of for IPv6, but there is no
way around this at this time in our IPv6 Transition evolution.

>5.2 Mixed scenario with relay to native IPv6
>
>   Suppose one or more of the sites described above acquire native IPv6
>  connectivity in addition to 6to4 connectivity. In this case it is
>   necessary to relay packets between the 6to4 realm and the native IPv6
>  realm. There must be at least one router acting as a relay.  There is
>  nothing special about this; it is simply a normal router which
>   happens to have at least one logical 6to4 pseudo-interface and at
>   least one other IPv6 interface.

Can you state the problem with more clarity for the reader you jump from
a vague problem statement to a conclusion.  And then say there is
nothing special about this but then have two pages of text to try to
explain a solution.  More discussion of the problem and some pictures
would be useful.

Also please define a "relay router".  The only time this is used with
routers is usually for the DHCP protocols to relay packets.  This is
important so we can see if the solution can be handled at layer 3 or
must go up to higher layers to perform the act of relaying.

>   An IPv6 router willing to act as a relay from native IPv6 to the 6to4
>  address space is known as a relay router.  It MUST advertise a route
>   to {FP=001,TLA=TLA624}/16 into the native IPv6 routing system.
>   Additionally, an IPv6 unicast routing protocol such as BGP4+ MUST be
>  used among the set of communicating 6to4 routers including the relay
>   router. The relay router MUST advertise whatever native IPv6 prefixes
>  are appropriate on its 6to4 pseudo-interface. These prefixes will
>   indicate the regions of native IPv6 topology that the relay router is
>  willing to relay to. Their choice is a matter of routing policy. It
>   is clearly desirable for network operators to carefully consider
>   desirable traffic patterns and topology when choosing the scope of
>   such advertisements.

In the first sentence it is not clear why you are doing this in the text
of the draft.  It then appears your saying use BGP4+ as an IGP ????
Are you suggesting that these are all BGP4 border router speakers?  
Any IPv6 router will inject site/local prefixes it can forward to and
6to4 is just another one potentially.  The special role of the relay is
not clear in the text.

>   A 6to4 site which also has a native IPv6 connection MUST NOT
>   advertise its TLA624/48 prefix on that connection, and IPv6 network
>   operators MUST filter out and discard any TLA624 prefix
>   advertisements longer than /16.

Do you mean over that connection or over that pseudo-interface?  It
could be the EGP connection has multiple purposes.  This is why I asked
about pseudo-interface nomenclature as its relevant for implementation.

>   The following algorithm would result in correct address selection.
>   Suppose that sending host B has a set {B} of IPv6 addresses, and the
>  DNS has returned a set {A} of IPv6 addresses for host A. Then B
>   performs a longest prefix match for each address in {B} against each
>  member of {A}, and selects as the address pair to be used that pair
>   with the overall longest match. This guarantees that a pair of TLA624
>  addresses will be selected unless there is a better match using
>   native IPv6 addresses, which is the desired result. In the case of a
>  tie the choice is arbitrary.

This is not how it works in reality.  First the host gets back a hostent
structure from its DNS client speakee (e.g. resolver) and
implementations send to the top address on the list from the resolver,
Second the addresses housed on the host are usually stored in the kernel
OS via a linked list or hash table, and this means a context switch
lookup and search for addresses.  The good news is that the recent draft
on source address selection will cover the 6to4 case correctly given it
is the address sent to the outgoing interface.  I think the above is a
nice wish but not reality and not clear it adds value to 6to4 and
entering another disciplines space.  So I suggest it be removed.

>   In practice address selection will proceed in two stages. First, a
>   call to gethostbyname2 [API] will return a set of valid destination
>   addresses. It is RECOMMENDED that these should be sorted in order of
>  longest match to the host's set of valid source addresses. It is then
>  the RECOMMENDED default that the host selects the first destination
>   address from that list and selects the source address with the
>   longest match.

Please used the new RFC 2553 term as gethostbyname2 is deprecated and
its getipnodebyname.  You say in practice agreeing with my point above
but then slip in this recommendation.  We should not be comparing and
getting addresses like this it is ideal and not existing practice and we
cannot keep building shims for IPv6 because of transition. I suggest
removing the recommendations.  

The word RECOMMENDED in RFC 2119 implies a SHOULD to implementors so
please make that a MAY I believe I have enough issues and implementor
arguments to make this an issue for any last call to the IESG.  Do not tell
impelementors how we compare and operate on Hosts when it affects
existing applications for TCP/IP.  I suggest using MAY if you must have
this in the draft.  

There is a performance cost trade-off here too.  And saying that the
hosts addresses can remain statically within the DNS resolver is a new
way to break renumbering so lets not go there.

I won't respond futher to the routing summary, ISP statements etc. Until
I get response to the questions above at this point. 

>5.4 Multihoming
>
>   Sites which are multihomed on IPv4 MAY extend the 6to4 scenario by
>   using a TLA624 prefix for each IPv4 border router, thereby
>   automatically obtaining a degree of IPv6 multihoming. The address
>   selection algorithm of the previous section will apply.

Thats a broad statement about that algorithm.  Can you defend it with
more explanation as users will read this for sure.  I think 6to4 does
nothing to harm or help Multihoming and its irrelevant to speak of in
this draft other than to say that maybe.  Pushing this src address
selection algorithm is not good as it has implementation issues and
choice and not in the space of standards work IMO.

>5.5 Transition considerations
>
>   If the above rules for routing advertisements and address selection
>   are followed, then a site can migrate from using 6to4 to using native
>  IPv6 connections over a long period of co-existence, with no need to
>   stop 6to4 until it has ceased to be used. The stages involved are

This will work with the address selection most implementors have
implemented today.  So you are saying above 6to4 won't work unless we
implement your address selection algorithm.  I think that is not true at
all.

>   3. Identify a 6to4 relay router willing to relay the site's
>   traffic to the native IPv6 world. This could either be at
>   another cooperative 6to4 site, or an ISP service. Configure
>   a default IPv6 route to that relay router, and have the relay
>   router configure a route to this site's 6to4 prefix.

This needs more discussion before it is stated as necessary.

>   4. When native external IPv6 connectivity becomes available,
>   add a second (native) IPv6 prefix to both the border router
>   configuration and the DNS configuration. At this point, the
>   address selection rule described above will determine when
>   6to4 and when native IPv6 will be used.

There you go again with the address selection rule.  First it is not a
rule and not required by this draft so why say its a rule?  More reason
why it should be removed from the draft and at a minimum MAY.  

>5.6 Usage with firewall or NAT
>
>   The 6to4 mechanisms can run exactly as described above in the
>   presence of a firewall at the border router.

Can you make some statement why this is true and why generically it will
not affect Firewalls.  Seems like a broad statement that should be
defended.

>5.8 Summary of impact on routing
>
>   IGP (site) routing will treat the local site's TLA624 /48  prefix
>   exactly like a native IPv6 site prefix assigned to the local site.
>   There will also be an IGP route to the generic {FP=001,TLA=TLA624}/16
>  prefix, which will be a route to the site's 6to4 router, unless this
>   is handled as a default route.

Exactly. So why all the relay routers?

>   EGP (i.e. BGP) routing will include advertisements for the
>   {FP=001,TLA=TLA624}/16 prefix from relay routers into the native IPv6
>  realm, whose scope is limited by routing policy. This is the only
>   non-native IPv6 prefix advertised by BGP.

It might be useful to state up front the relays only affect EGP.  But
why have a policy that does not permit 6to4 to be part of the IPv6
prefixes provided on some links.  

Enough for this round.  I don't think the entire Multicast/Anycast
discussions is necessary but will await responses on this before I send
that input.

thanks
/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jul 1999 12:05:02 -0500

Jim Bound wrote:
> 
> Adding the "relay routers" has made this more complex.  

Possibly, but without them it is basically useless. The BGP4
stuff turns out to be key to deploying this, and a couple
of BGP experts confirmed that the model works.

> I think now we
> need pictures for this depicting the issue and solutions.  

Yes, I presented a bunch of extra pictures in Oslo. Got to get
an ASCII representation of them into the next version.

Jim, we'll pick up your comments in detail during the next revision.
BTW, if the multihoming proposal is accepted by INPNG WG, then all 
the stuff about address selection in 6to4 can go away.

  Brian

---

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jul 1999 20:37:54 -0400

Hi Brian,

>of BGP experts confirmed that the model works.

I spoke to one of them too.  But I think I asked some pertinent
questions in my reply I would like to get answers to please?
Its imperative we as a Working Group understand each detail and meaning
of 6to4 as it affects implementation.  Maybe the BGP experts can chime
in here on the list? 

>an ASCII representation of them into the next version.

Could we get pointers to your slides from Oslo?

>Jim, we'll pick up your comments in detail during the next revision.

Meaning you will respond to my comments line by line as I took the time
to write them so you could respond to each comment for the most part?

>the stuff about address selection in 6to4 can go away.

Well I am not sure about that as I have no idea what this means, but
like others await a draft.

/jim

---

From: Cyndi Jung <[email-masked]>
Date: Tue, 27 Jul 1999 18:42:23 -0700

>of 6to4 as it affects implementation.  Maybe the BGP experts can chime

If you'll accept me as a stand-in for a BGP4+ expert, I'll try to explain
how this is reasonable - and even helps - BGP.

The router that is willing to perform the relay function must advertise
this willingness into the BGP routing information in the form of the
prefix 2010::/16 (it is called NLRI in BGP-speak, but it is effectively
an advertised route).  If the relay router is not itself a BGP speaker,
some means of advertising reachability to 2010::/16 through the IGP
to the BGP speaker can be arranged, and the BGP speaker import the prefix
into the BGP information from the IGP information - even static routes could
be used to route the data frames from the BGP-speaker to the relay router.

The fact that multiple relay routers can perform the service, and so announce
reachability through them for 2010::/16 does not represent a problem for BGP -
any BGP speaker will learn of no more paths to 2010::/16 than it has
active peers - and will use the "best" path of all these for forwarding and
for in turn announcing to other peers - those that do not already know,
subject
to any filtering or aggregation policies, though there is not much more
aggregation available for 2010::/16.  If there turns out to be many relay
routers in the global, connected system, it can't become a large burden to
the system as a whole, and so no single relay router needs to become a "hot
spot", through which all these packets need to go for forwarding.  The
solution here can scale as required.

The datagrams addressed to any address beginning with 2010 will be forwarded 
along the "best" path to the "closest" relay router to the sender, and that 
relay router will perform the 6to4 encapsulation, using the IPv4 address found
in the 32 bits following 2010.  If that IPv4 address is "good" (IPv4 path
from the relay router to that IPv4 address), the packet is delivered to
the system with that address.  That system must then decapsulate the IPv6
frame
and forward it along to the IPv6 destination using local IPv6 routing
information.

What would be really bad for BGP is if each of these 6to4 domains needed
to inject their /48 prefix into the BGP routing information.  They would
be as aggregateable as the IPv4 addresses they are derived from, so there
is a potential to keep it under control, though there is nothing to really
force the control (it is the hands of humans), and we run the risk of
duplicating the entire IPv4 routing information at the BGP level - there 
is nothing to naturally bound this repetition of information as there is 
with the 2010::/16 "anycast prefix".  This has scaling problems right away.

These 6to4 domains can receive packets through the border router and relay
router mechanism, but they also need to be able to send IPv6 frames to 
non-6to4 domains - but they need some path to the BGP routers already,
and will likely follow a ::/0 route to the backbone, or more specific
prefixes if that information is in the IGP.  The only system in the 6to4
domain that really needs to be aware of the fact that it is part of
a 6to4 domain and do something special is the device that owns the IPv4
address that the IPv6 prefix is derived from.

The border router, that has used it's IPv4 address to provide IPv6
addresses to the 6to4 domain, needs to accept encapsulated IPv6 in 
IPv4 frames from anybody, basically.  I don't know how different
this is from being willing to forward datagrams of other encapsulations.

Cyndi

---

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jul 1999 22:43:59 -0400

Hi Cyndi,

>how this is reasonable - and even helps - BGP.

I will for sure.  Thanks........  I am familiar with 1771-74, 1997, and
the new 2283 to add v6 (I have some offline questions to Tony Bates now
on that spec too).  But I am not an impelementor in this space but must
know the details of this and it was clear to me prior to the relays.
Also I think this is a superb mechanism but now its time to grill it
just in case even though I like it.

>solution here can scale as required.

I agree with all that but why can't the IGP learn the best paths given
the capability of the IGP?

>and forward it along to the IPv6 destination using local IPv6 routing

Aha Ha !!!  I did not see this in the spec or did not parse it that the relay
router will be doing encapsulation?  I will have to look again I guess.

So this is an optimization to get 6to4 prefixes routed to where they
would be encapsulated and to where they get decapsulated?

If so why not or can't our IGPs available do the routing policy to make
this happen with the std routing dameons we all use?

>address that the IPv6 prefix is derived from.

I agree with both sentence blocks above now that you have cleared it up.

So what we want to do is have the routers that will see 6to4 prefix the
earliest in the topology as the packet is enroute, to perform the the
encap and send so the prefix does not have to be advertised thru the
entire topology (e.g. /48)?

I can understand that but I would prefer if it was done using the IGP
and if it can't I would like to know why not for my own sanity?

I also will say the spec has to discuss this as you did and then relate
what it means as a bottom line as I do in my responses.  

If I got this right now I will go to the next step of this spec review?

thanks
/jim

---

From: Cyndi Jung <[email-masked]>
Date: Tue, 27 Jul 1999 23:15:46 -0700

>router will be doing encapsulation?  I will have to look again I guess.

Maybe I better look again - this made sense to me so I said it, but perhaps
the draft says something else?  I'll check - maybe it doesn't :-)

>this happen with the std routing dameons we all use?

They can - though they don't have good assurance that the IPv4 path to
the 6to4 domain border router is unobstructed.

>and if it can't I would like to know why not for my own sanity?

You would certainly route using the IGP towards the system advertising
reachability to 2010:/16.  If you are sure that your IPv4 path is unobstructed
and connected, you could decapsulate even at the source, or any router
between the source and the advertiser of 2010::/16.

I think the focus on BGP here has been to calm the fears that 6to4
would instantly overburden the BGP routing information base.  Also, once
your datagram has made it to any BGP speaker, it is assumed to have
reached some system with an unobstructed IPv4 path to the border
routers of all 6to4 domains.  

Also, if you have learned of a route through your IGP and the same
route through your EGP, the normal preference is to use the IGP-learned
route.  So, if your own AS had systems offering encapsulation service,
your datagrams would be encasulated within your AS and leave your AS
as an IPv6-in-IPv4 packet.  Within your own AS, if you are using 6to4,
you would want to route on the longer prefixes, up to /64, and not
encapsulate the frames in IPv4.

Cyndi
  
>what it means as a bottom line as I do in my responses. 

The question is usually "does it scale" and this, I think, says it does.
 
Cyndi

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jul 1999 09:55:08 -0500

Two quickie comments. Also I sent the slides to [email-masked]
so I suppose they will appear on the web site.

1. thanks Cyndi for all that good input. Haven't thought enough
yet about 6to4 and IGP (my initial assumption was that there
was absolutely nothing to say about the IGP).

2.

Jim Bound wrote:
...
> Meaning you will respond to my comments line by line 

Meaning I'm accumulating all the comments in one folder so that
I can deal with them all in one pass when my day job permits.

  Brian

---

From: Jim Bound <[email-masked]>
Date: Wed, 28 Jul 1999 21:22:56 -0400

ack Brian... I hear you about the day job I am now getting tired and
catching up a night.

/jim

---

From: Bob Fink <[email-masked]>
Date: Wed, 28 Jul 1999 19:56:00 -0700

>so I suppose they will appear on the web site.

If you mean your ngtrans 6to4 slides, they are up at:

<http://www.6bone.net/ngtrans/oslo/6to4-02-prstn.ppt>

Bob

---

From: Jim Bound <[email-masked]>
Date: Thu, 29 Jul 1999 00:07:53 -0400

good slides Brian...nice job.....
/jim