(ngtrans) Input Part 1: draft-ietf-ngtrans-6to4-03.txt

[Jim Bound <[e-mail]>]

Brian and Keith,

Here is input part 1 from several members of the Compaq IPv6 engineering 
team (Jack McCann, Sowmini Varadhan, Gerri Harter, Vlad Yasevich, Ken 
Powell, Mary Clouter, and Jim Bound).  We will send you edit type issues we
found in the technical spec review we did offline.  We will get part 2
input to you after the Wash D.C. IETF meeting.

First some general issues we want to provide you that we believe will
help make the spec more clear in general.

1.  Please define in a terminology section Native IPv6 Address/space and
    6to4 Address/space for IPv6 addresses.  We also believe you have enough 
    new terminology that you should have a specific terminology section.
2.  Please label the sending and receiving rules clearly in the spec
    as "Sending Rule" and "Receiving Rule" and then reference them
    as such in the spec.
3.  Hosts or End-Nodes are not doing 6to4 but only Routers should be
    more strongly stated.
4.  Clarify by "advertisements" that these are router-to-router 
    to avoid confusion to anyone that these are ND advertisements
    to hosts.  Through-out the spec.

Technical Input:

2.1 Address Selection Algorithm.

The spec should get out of the business of specifying this and simply
reference draft-ipngwg-default-addr-select-00.txt as a pointer to how
this is done.  This greatly affects all non-router IPv6 implementations
and it is a complete set of work on IPng we will resolve.  But we
strongly believe a Native IPv6 prefix is preferable to using a 6to4
address for the destination, for deployment, when the Hosts first attempt
a connect.

5.2.2 Summary of relay router configuration

   On its 6to4 IPv6 pseudo-interface, the relay router advertises
   whatever IPv6 native prefixes its local policy permits, from among
   those reachable through its native IPv6 interface. In the simplest
   case, a default route to the whole IPv6 address space could be
   advertised. It has been suggested that these routes could actually by
  advertised along with IPv4 routes using BGP4 over IPv4, rather than
   by running a separate BGP4+ session.

We cannot see the benefit of discussing BGP or BGP+ in the spec.  But if
you want to talk about it please define how it will work, which is a lot
of work for you authors.  But it is not needed.  But if you want to
provide an appendix with diagrams and how BGP4 vs BGP+ will work that
may be useful to realworld network operators without a doubt, but not
clear it is needed in this specification.  And in its present terse form 
it is difficult at best to apply applicability assertions to the spec based 
on the above text.

It may also be wise to get out of the business of trying to explain how
route-exchanges are done within the spec.

Send/Receive rule issues:

It looks like the sending rule below has a bug, or needs an additional clause.
It currently says:
[sending_rule]  from section 5.1 of [6to4]:
        if the destination address of an IPv6 packet is non-local
           and the destination prefix is 2002::/16
           then
               encapsulate the packet in IPv4 as in Section 3
               with destination address set to the NLA value V4ADDR;
               queue the packet for IPv4 forwarding.


[receiving_rule] from section 5.1 of [6to4]
   A simple decapsulation rule for incoming IPv4 packets with protocol
   type 41 MUST be implemented:
          Apply any security checks (see Section 8)
          Remove the IPv4 header
          Submit the packet to local IPv6 routing.

Our conclusion is:
-----------------

It appears that it is  not just the "destination address of an IPv6 packet"
to which [sending_rule] must be applied, but to *any* destination
address e.g., nexthops for packets being forwarded. 

Reason:
------

Consider the following scenario (V4ADDRs are picked for the sake of
illustration only!)

    ..............                      ................
    .    6to4    .                      .   6to4 site B.           ........
    .            .                      .              .           .      .
    .   site A   .                      .     --Br2------ V4 WAN ---- Dr  .
    .            .                      . .../         .           .      .
    . Ah ---  Ar -------- V4 WAN ---------- Br ----- Bh .           . 6to4 .
    .            .                      . `. \`.       .           . site .
    ..............                      ...:.|.:........           .   D  .
                                            : \ :                  .      .
                                            `. |`.                 ........
                                             . \   .
                                 native ipv6 .  Cr  .
                                             .   |  .
                                             .  Ch  .
                                             ........


Glossary:

Site A is a 6to4 site with a host Ah and a router Ar (addresses
       are not relevant to the example).

Site D is a 6to4 site with V4ADDR 10.10.80.60 and 6to4 router Dr.
         Dr has the addresses 10.10.80.60,
		     2002:0a0a:503c::10.10.80.60

Site B is a 6to4 site with V4ADDR 9.254.253.250 with  routers:
         Br2 (6to4 router) addresses  9.254.253.251
		                      2002:09fe:fdfc::9.254.253.251

	 Br (relay router) addresses 9.254.253.252,
                                     2002:09fe:fdfc::9.254.253.252

Site C is a native V6 site with the onlink prefix abc::/64  with
         Ch (host) address abc::c2
         Cr (V6 router) address abc::c1

Consider a packet originating in site D  to site C. To simplify the number
of nodes, we can assume without loss of generality that the packet 
originates in Dr and is being sent to Ch.

First, the routes on the various nodes:
As we understand it, Br convey to Br2 that routes to abc::/64 are reachable
from Br2 through Br using the methods describe in  Section 5.2.2, 
page 10.  

So routes on Br2 look like

dst                    gate                            interface
---                    ----                            ---------
abc::/64             fe80::9.254.253.252               phys_interface
		     (i.e., link-local addr of Br)

and Dr has a route

abc::/64             2002:09fe:fdfc::9.254.253.251    virt_6to4_interface
			(i.e., addr of Br2)

If Dr wants to send a packet to Ch, 
 - it queries DNS, figures out that Ch is abc::c2
 - constructs packet
         2002:0a0a:503c::10.10.80.60 > abc::c2 [data]

 - the routing table says that the next hop for abc::/64 is 
   2002:09fe:fdfc::9.254.253.251. 

   Now Dr gets to resolve 2002:09fe:fdfc::9.254.253.251 to 
   a link layer address.

Question
--------
What is the link-layer address of a node on a 6to4 network? How 
does one obtain it? Do you just implicitly pull it off the 2002:... address
as the V4ADDR  part? 

If yes, then this is not covered by the [sending_rule] as currently
defined in [6to4], and which only applies to packets with destination
of 2002::/16 in the IPV6 packet header.  Or, maybe, have a section addressing
"Address Mapping over 6to4 networks" just like the other "IPV6 over foo"
specs.

If the answer to the question is no, then what does Dr do  to 
resolve the next hop into a link-layer address?

-------------------------------------------------------------------

Under Section 5.1 for regarding aligning datalink.  We sent you input
for 6over4 on this issue too.

Also, regarding the comments about Encapsulation in Section 3, which
appear to be pulled out from [6over4], here's the mail from Cyndi.
We believe this text can be removed without any harm to the spec or
implementation.

>From [e-mail] Tue Aug  3 21:53:19 1999
From: Cyndi Jung <[e-mail]>
Subject: Re: RFC 2529 (6over4) 
  :
  :
  :
>Section 3
>
>The reference to the "datalink" header below is confusing, because it
>is not clear if the intended datalink refers to the IPV4 header or
>the physical (e.g., ethernet) link header. 
>   151     If there are IPv4 options, then padding SHOULD be added to the IPv4
>   152     header such that the IPv6 header starts on a boundary that is a 32-
>   153     bit offset from the end of the datalink header.
>
>Unless it changes the intended meaning, it appears that it could
>be stated more directly as:
>  "If there are IPv4 options, then padding SHOULD be added to the IPv4
>   header such that the total size of the IPv4 header is a multiple of 
>   32 bits".

cmj> Actually, I think the paragraph is unnecessary, as the IPv4 header MUST
cmj> be padded to a multiple of 32 bits, as dictated by the IPv4 length field,
cmj> which expresses the number of 32-bit words in the IPv4 header :-)  Maybe
cmj> we should remove the paragraph since it is not only unnecessary but
cmj> confusing?


Section 5.3 Variant scenarios with tunnels.

This section should be expanded with examples and as one case which
is in the scope of this works is where a 6to4 node sends to a native
IPv6 site that does not support 6to4?  There are others.  

Src 2002::/???? to Dst 3ffe::/??? will not work without 5.3 above and we
feel strongly it should be discussed in this transition mechanism.

We still will provide input later on the following sections:

5.4 Fragmented Scenarios
5.5 Multihoming
5.6 Transition Considerations
5.7 Usage with Firewall or NAT (this is very important to review)
5.8 Usage with Intranets
5.9 Impact on Routing 
9.0 Security Issues

thanks
/jim for the Compaq IPv6 Eng Team