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

From: Sowmini Varadhan <[email-masked]>
Date: Tue, 11 Apr 2000 14:03:12 -0400 (EDT)

A few questions about draft-ietf-ngtrans-6to4-04.txt (which clarified
several details missing in draft*6to4-03.txt!)

- the spec does not insist that  the 6to4 router must have V4ADDR
  configured on one of its interfaces. All I could find stated was:

  "2. IPv6 Prefix Allocation

   Suppose that a subscriber site has at least one valid, globally
   unique 32-bit IPv4 address, referred to in this document as V4ADDR.
   This address MUST be duly allocated to the site by an address
   registry (possibly via a service provider) and it MUST NOT be a
   private address [RFC 1918].
    :
    :
   The subscriber site is then deemed to have the following IPv6 address
   prefix, without any further assignment procedures being necessary:
      Prefix length: 48 bits
      Format prefix: 001
      TLA value: 0x0002
      NLA value: V4ADDR",

   and, in Section 5.1,

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

  But, there is only 1 node in the 6to4 site that will accept  and decapsulate
  packets with V4 dst set to V4ADDR, so this node MUST be a 6to4 router
  for sending_rule to be deployed. So it looks like there must necessarily
  be at least 1 6to4 router in a 6to4 site that has V4ADDR configured on
  one of its interfaces, and, if there are multiple 6to4 routers in a site
  that use the same V4ADDR, only one of these will actually execute
  the decapsulation_rule, so 6to4 sites should (SHOULD?) use a different
  V4ADDR for each 6to4 router?

- I was having some difficulty parsing the statement below, taken from
  Page 5 (in the newly added Terminology section):

  "Note: an IPv6 node may in some cases use a 6to4 address for a
   configured tunnel. Such a node may function as a 6to4 host and it may
   also serve as a 6to4 router for other 6to4 hosts, but these are
   distinct functions."

 Is this statement trying to say that
  o a host with a 6to4 address on its config-tunnel interface, 
              and simultaneously be a 
  o a 6to4 router on its virtual 6to4 interface?

  Or is it trying to say something else?

- Anything about NUD on 6to4 links? For example, does the 6to4 link 
  have link-layer addresses (and therefore options) for NUD? It feels like
  link-layer options are redundant for NUD, for the same reasons that
  they are redundant over configured tunnels. 

- 2010 should be 2002 in the lines taken from Section 5.4 below:

  "2010::/16 routing advertisements within the native IPv6 world.  Like.."

  "routing policy to ensure that traffic to 2010::/16 follows the.."

--Sowmini

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Apr 2000 14:59:53 -0500

Sowmini,

Good comments. Most of them I can deal with as text clarifications, but 
what do you recommend we should say for NUD?

FYI, the multicast section will be largely removed in the next version;
it's broken. Dave Thaler offered to do a separate draft on multicast.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Apr 2000 14:28:25 -0500

Sowmini Varadhan wrote:
>   ....So it looks like there must necessarily

While thinking how to fix the text for this comment, I concluded that we can't 
insert the SHOULD since it would preclude anycast towards the decapsulator. Since
6to4 is stateless, there is no reason to prevent anycast. The first part of the
sentence is valid and I've inserted a corresponding requirement.

There will be fixes for the rest of your comments in the next version.

Thanks.

   Brian