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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Sep 1999 15:00:40 -0500

Jim,

I will be making various changes to the 6to4 draft in response
to your comments below. See comments on your comments.

   Brian

Jim Bound wrote:
> 
> 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.

OK, actually I've just dropped the specific ref to 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.

6to4 certainly doesn't care, as long as it gets the addresses somehow.

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

Not wearing this hat. Wearing my IAB hat I do care, but that's
a separate discussion.

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

I don't know anything about how a particular router
might work; all I know is that if the packet has a local prefix
I mustn't encapsulate it. So I don't see what more I can say here.
In fact I can and will simplify the algorithm a bit, which may
make it clearer.

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

No, this bit is completely orthogonal to the relay router discussion,
which is only relevant for non-6to4 addresses. 

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

OK, I have to rephrase this for clarity. Of course we need
IPv6 routing between the three routers in your picture. What I mean
is that Router A doesn't need IPv6 routing to talk to another
Router Z across the other side of the IPv4 Internet. 

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

I've moved it up, but don't expect a precise terminology because
it's obvious from the 6over4 discussion that different implementors
have different ideas about this. It's a thinking aid, not a
mandatory feature.

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

"pure" is without relay routers. Bad word though, I will remove it.

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

Sure, so can IPSEC or any other per-packet processing, but the
real scaling hit would be if we screwed up route aggregation.
I will add a note on encapsulation overhead.

> 
> Also anytime tunneling is used it creates a net mgmt issue.  

The specific claim for 6to4 is that it doesn't create a tunnel
management issue. What it does is add a small delta to
route management and routing policy management.

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

Indeed.

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

I will try to rephrase.

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

There is nothing special about the router but the scenarios
are complex to explain. I've added more pictures.

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

Absolutely not. It's a 100% pure layer 3 packet forwarding role.
I think the revised text makes this clearer.

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

Not at all. I need to rephrase it to make it clear that BGP4+
is used in its normal role entirely.

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

I've tried to clarify this by spelling out the various routing domains
involved.

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

OK, I've stripped all this down to the bare bones of what has
to happen for 6to4 to work, and moved it earlier in the
draft. However, believe me, if packets aren't sent with
the source starting with 2002::, 6to4 ain't going to work.
I agree most of it should now be covered elsewhere.

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

OK

> 
> 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 it is now irrelevant. It's gone...

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

Sure. I do want to keep the mention of multihoming though.

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

I'm not sure you're right but I've tweaked the wording.

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

See rewrite of 5.2

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

See earlier comments.

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

I guess it depends on the definition of firewall, and people have
written whole books on that. I will weasel-word it.

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

See earlier rewrite of 5.2
> 
> >   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.

To guard against pollution of the IPv6 routing tables by long
prefixes.
> 
> Enough for this round.  I don't think the entire Multicast/Anycast
> discussions is necessary 

I think it's necessary for the record; if we leave it unmentioned
we will get questions the day the RFC comes out.

but will await responses on this before I send
> that input.
> thanks
> /jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 27 Sep 1999 09:53:33 -0400

thanks Brian.......ACK.......
/jim