Subject: (ngtrans) Re: draft-ietf-ngtrans-broker-03.txt

From: Richard Black <[email-masked]>
Date: Tue, 25 Jul 2000 05:21:16 -0700

I would like to make several comments on the current
draft-ietf-ngtrans-broker-03.txt document.  For background, I am the
principal author of the Microsoft Research IPv6 Tunnel Broker, which
is currently in beta.

1.  First, I am unhappy about the suggestions that the prefix length
    supported by brokers and/or the allocations made to the clients
    should be either /64 or /48.  The draft reads:

      "This prefix can be ether [sic] 48 or 64 bits."

    Later it reads

      "[the broker] chooses the IPv6 prefix (e.g., /128, /64 or /48)
       to be allocated to the client."

    which is much better.  There are several issues here.

    a) No user should be given more addresses than they can correctly
       configure.  If an address range is allocated to a user then the
       tunnel server at the ISP will have a (pseudo-) static route for
       that address range pointing at the user's end of the tunnel.
       The user is likely to have a default route pointing back at the
       ISP.

       That user must ensure that packets sent to any address within
       that range are handled correctly.  If the addresses are not in
       use then an ICMP unreachable should be returned.  If, however,
       a user is allocated a range larger than they can assign, then
       they must ensure that other addresses are routed to their
       loop-back (or discard) interface as appropriate to ensure that
       the packets do not bounce back and forward between the user and
       the ISP.

       Many users may not be aware of this responsibility (or
       sufficiently technically proficient), and so allocating them a
       range larger than that which they can reasonably handle is just
       going to lead to support issues for the ISP.

    b) Part of the reason for CIDR and the specific prefix in IPv6
       notation was to get away from clasfullness and hard and
       inflexible divisions of the address space.

       Whilst it may be useful to have some common defaults, and for
       BGP visible Autonomous Systems to have some maximum on the
       number of prefix bits allocated, within one agregatable route
       (e.g., between an ISP and its customers) there is no reason to
       mandate by standard any particular fixed prefix allocations.

       An ISP should be free to make this division any way that it
       chooses.  I should think (for example) that a /56 is likely to
       be sufficient for most organisations.  [For reference the
       MSR broker presently supports /48 /64 and /128 so I'm not
       saying this just because I've done it.]

       The broker draft should not appear to mandate any particular
       standard prefix allocations (other than /64 and /128).

2. Secondly, I'm unhappy with paragraph 7 of section 2.6 (para 3 of
   page 7) in which it is suggested that a broker use RSH to configure
   clients.

   Since IP(v4 or v6) level configuration is inevitably a root /
   Administrator function I do not think that any RFC should suggest
   that a user configure their machine to have remote root RSH
   access.  [RSH may be appropriate between the broker and the server
   however]

   Likewise, none of the security effects of extending use of DHCP
   beyond a single administrative boundary have been considered, and
   this is also likely to be unreasonable.

   This paragraph should simply be removed.  

3. I am unclear as to the utility of a MIME attachment to achieve user
   configuration.

   Few users run an MUA with root privileges (and again its unclear
   whether this should be encouraged),  likewise the machine on which
   the email is handled need not be the same as the machine which will
   be used for the client end of the tunnel.

   A configuration script seems much more flexible (if less pretty)
   and has the advantage that the user can check it for safety, and
   clever administrator can modify it.   Besides which, how is a MIME
   agent going to decide which interface to allocate the /64 to, or
   how to subnet a /48 or .....

Richard Black
Microsoft Research

---

From: Alain Durand <[email-masked]>
Date: Tue, 25 Jul 2000 11:51:08 -0700

> principal author of the Microsoft Research IPv6 Tunnel Broker, which

Richard,

Thank you very much from your comments.

>     which is much better.  There are several issues here.

You're right, The first paragraph  should be made more consistent with
the second one.

>        standard prefix allocations (other than /64 and /128).

/48 is comming from the address architecture that specifies that
a site prefix lenght is /48. I know that there are discussion with
the registries and the ISPs to change this.
However, I agree that whatever is connected via the tunnel broker
may or may not be a "site", thus the /48 boundary may or may not
apply. We may add some text to say that and relax the boundary
limitation.
We should discuss this point in Pittsburgh.

>    This paragraph should simply be removed.

We could probably be less specific in this paragraph.

>    be used for the client end of the tunnel.
The MIME type is not necessairely sent over a mail message.
It's just a framework to convey configuration parameters
ant let the client do the actual configuration itself.
This is somehow more secure than blindly executing a script
downloaded from a remote location. Also, il could make hte life
of router implementing a tunnel broker client easier.

>    how to subnet a /48 or .....

This is a local configuration matter. You can have a site local topology
and use router renumbering messages to change this to the prefix
allocated
by the tunnel broker.

    - Alain.

---

From: Randy Bush <[email-masked]>
Date: Tue, 25 Jul 2000 12:36:33 -0700

> the registries and the ISPs to change this.

ad hat off, isp and registry watcher's hat on.  i suspect that these
boundaries will be fluid for a fair while, and would not recommend
hard coding any boundaries.

randy