Subject: Comments on unmaneval-00

From: "Chirayu Patel" <[email-masked]>
Date: Wed, 19 Nov 2003 09:28:38 +0530

Hello,

Comments in unmaneval-00.

Pekka has given comments in the past, but I am feeling too lazy to go
through them, and remove duplicates, iron out conflicts.... :-) 

CP

High Level
----------

0.

The document probably needs to be summarized in a table form.

The table can have the following columns:

a) Case

   - A, B, C, D

b) DNS server discovery

   - DHCPv4

   - DHCPv6

   - Static

   - .....

c) Publishing IP address mechanisms

   - Manual

   - DDNS

d) Recommended Connectivity mechanism(s) (to the Internet)

   - 6to4

   - native IPv6

   - Tunnel

   - ....

e) Prefix delegation method

   - Static

   - RA

   - DHCPv6

f) Type of gateway

   - router

   - ND proxy

   - L2 bridge

   - v4 only (NAT, with or without proto-41 filters)

I know it will be a bit tough to organize all this data in a table form
but, IMHO, it will be very beneficial in the future.

 1.

,----[ text from unmaneval-00 ]
|    During the transition phase from IPv4 to IPv6 there will be IPv4
|    only, dual stack or IPv6 only nodes. In this document, we make the
|    hypothesis that the IPv6 only nodes do not need to communicate with
|    IPv4 only nodes; devices that want to communicate with both IPv4 and
|    IPv6 nodes are expected to implement both IPv4 and IPv6, i.e. be
|    dual stack.
`----

I don't agree with such an hypothesis. As long as IPv6-only devices are
not barred, it is just a matter of time when some IPv6 application proves
to be too sexy (for IPv4-only devices) to resist.

From the perspective of this document, mechanisms that can be used to
bridge IPv4-only and IPv6-only devices should be evaluated.

The same comment applies to the text in section 3.2.

 2.

This document should also consider connectivity and naming requirements
for IPv4-only, dual, and IPv6-only internal gateways, and all the hosts
that are behind these gateways.

 3.

,----[ text from unmaneval-00 ]
|    To gauge the difference, we consider the case of a host engaging in
|    Voice over IP: it will maintain its address reachable all the time,
|    and it will send a large amount of traffic whenever it is engaged in
|    a conversation. According to classic figures collected by AT&T, the
|    average duration of a conversation is around 100 seconds, and a
|    business telephone is likely to be engaged in a conversation about
|    10% of the time, which implies starting a conversation on average
|    every 1000 seconds. The average load sent by a tunnel client to the
|    tunnel server will be 10% of the average data rate of the client;
|    assuming a 16kbps codec and 50 packets per second, the data rate of
|    the client sums up to about 51 kbps, hence an average load on the
|    tunnel server of 5 kbps. The load sent by the tunnel client to the
|    tunnel server will be about one exchange of bubble per minute, to
|    defend the address, plus one bubble exchange at the beginning of
|    each session with a new peer; adding all headers, the bubble size is
|    about 144 bytes, which results in about 20 bps of traffic on the
|    server. In short, the amount of traffic seen by the Teredo server is
|    250 times less that the traffic seen by a Teredo client.
`----

This text is misleading.

  a) It does not mention that the traffic that will be seen by Teredo
     relays (which will equal to the traffic seen by the client).

  b) VoIP is not the best example. In the initial phases the applications
     will be p2p or client-server (http). For client server applications
     most of the traffic will be from the server to client, and in that
     case the advantage of TEREDO server would not seem to be that great
     because the servers (e.g. http server) will not be using TEREDO.

     Considering the number of messages (TEREDO + the VoIP protocol) to
     be exchanged, VoIP call setup may be too slow. This may be another
     reason for not using VoIP.

 4.

,----[ text from unmaneval-00 ]
|    The tunnel approach is more expensive to provide, because the tunnel
|    server will have to carry a much larger amount of traffic. It is
|    unclear that a tunnel service can be provided as an almost free
|    "supporting infrastructure", except perhaps if the service was
|    directly provided by the same ISP that already provides IPv4
|    connectivity to the unmanaged network.
`----

This text is also mis-leading. For complete IPv6 connectivity Teredo
Relays also have to be deployed, and they don't seem to be an almost free
"supporting infrastructure".

 5.

,----[ text from unmaneval-00 ]
|    discovery. In short, Teredo is more complex, but the complexity is
|    not overwhelming.
`----

:-)

This is very subjective. Probably some statistics about "Lines of Code"
or "number of messages" might be a logical comparison criteria.

 6.

,----[ text from unmaneval-00 ]
|    Teredo appears to be a good fit for providing IPv6 connectivity to
|    hosts behind NAT, in case A of IPv6 deployment. The service is
|    designed for minimizing the cost of deploying the server, which
|    matches the requirement of minimizing the cost of the "supporting
|    infrastructure" for peer-to-peer applications.
`----

Mis-leading as discussed above.

 7.

,----[ text from unmaneval-00 ]
|    The most reasonable solution would be to develop a tunnel service
|    specification that is compatible with Teredo, so that a given host
|    could be configured to use either Teredo or the tunnel service,
|    depending on the server configured in the dual stack host.
`----

I beg to differ.

Tunnel Service works with all kinds of NATs, is simple, and requires a
server to talk to all other IPv6 clients.

Teredo does not work with all kinds of NATs, is complex, and requires a
relay to talk with all other non-TEREDO IPv6 clients.

 8.

Text regarding naming service should be added in Section 2.

 9.

,----[ text from unmaneval-00 ]
|    The gateway must be able to acquire an IPv6 prefix, delegated by the
|    ISP. The possible mechanisms are RA proxy and explicit prefix
|    delegation.
`----

Rephrase to

,----[ new text ]
| The gateway must be able to acquire an IPv6 prefix, delegated by the
| ISP. The possible mechanisms are ND proxy and prefix delegation using
| DHCPv6, and RA (gateway is an L2-bridge).
`----

Section 3.1.3 for "Gateway as L2 bridge" should be added.

Section 5.1.1 will need minor modifications.

10.

,----[ text from unmaneval-00 ]
|    The principle of RA proxy is simple: the gateway issues a "router
|    solicitation" message on the serial link, receives a "router
|    advertisement", learns a network prefix from the advertisement, and
|    advertises the same prefix on the unmanaged network.
`----

Maybe this is how RA proxy was envisaged. But, it is not a complete
representation of the functioning of an ND proxy.

,----[ text from unmaneval-00 ]
|    This sharing has effects on neighbor discovery protocols, and
|    possibly also on other protocols such as LLMNR that rely on "link
|    local multicast". These effects need to be carefully studied.
`----

Remove.

11.

ISATAP does not seem to be a suitable mechanism to be used within an
unmanaged network as these networks are so trivial that they will always
support native IPv6.

In case, you folks feel that ISATAP (within the network) is *really*
required, then ISATAP will be applicable to both case B, and C. Parts of
section 4.1.3 also need to be modified.

Section 4.1.3, last paragraph that talks of usage of ISATAP to provide
IPv6 Internet connectivity can be retained.

12.

Section 5 seems to be written in a bit of a hurry. :-)

There are few things that are missing.

  a) Mechanisms to provide connectivity to IPv4 networks
  b) IPv4 address assignment mechanisms.
  c) Naming mechanisms for IPv4.

A read of Section 5.4 (unman-scenarios-03) is needed before re-writing.

Semi-editorial
--------------

16.

,----[ text from unmaneval-00 ]
|    The issues involved are described in the next chapters. This
|    analysis outlines two types of requirements: connectivity
|    requirements, i.e. how to ensure that nodes can exchange IP packets,
|    and naming requirements, i.e. how to ensure that nodes can resolve
|    each-other's names.
`----

Rephrase to

,----[ new text ]
| The following sections evaluate various transition mechanisms that may
| be used for cases A, B, C, and D (as defined above). There are two
| requirements in each case: 1) connectivity requirements i.e. how to
| ensure that nodes can exchange IP packets, and 2) naming requirements
| i.e. how to ensure that hosts can resolve other names of other nodes
| (local, and remote), and publishing their IPv6 addresses on the
| Internet.
`----

Another paragraph that describes the document organization (Section X 
describes foo, Section Y describes bar etc) can also be added.

17.

Rename section 3.1 to Connectivity. And, within that section explain that
the only thing needed for connectivity to the IPv6 Internet in this case
(case B) is prefix delegation.

18.

Come to think of it, Connectivity means two things - 1) how are addresses
assigned (to hosts in the subnet), and 2) what is needed for the actual
connection apart from executing IPv6.

For case B, only "1)" needs to be answered as the actual connection will
happen with native IPv6.

For case A, in the description of TEREDO, and "tunnel broker", the
address assignment part should be mentioned.

The same comment (as for case A) applies for case C. 6to4 mentions
address assignment but "Tunnel broker" does not.

19.

,----[ text from unmaneval-00 ]
|    Just using DHCPv4 will not be an adequate solution for IPv6 only
|    local hosts. Three solutions have been envisaged for these hosts:
|    either using DHCPv6 to obtain the address of the DNS server; sending
|    the DNS requests to a well known IPv6 address; or sending the DNS
|    requests to the IPv6 address of the gateway itself.
`----

Specify why DHCPv4 will not be an adequate solution. Also add a reference
to DHCPv4.

This paragraph should be moved to section 3.3, and it should be reworded
to say that there are four solutions. Each subsection can present the
solutions (as it is now) and their pros/cons.

20.

,----[ text from unmaneval-00 ]
|    Another potential limitation of the technology is the reliance on
|    publicly accessible "6to4 relay routers" that accept packets from
|    6to4 routers and relay them to the "regular" IPv6 Internet. These
|    relays all listen to the same IPv4 anycast address [6TO4ANYCAST],
|    which enables gateways to start operating as 6to4 routers without
|    requiring any explicit configuration. As the deployment of IPv6
|    progresses, a growing fraction of the traffic originating from 6to4
|    routers will have to be carried through these relays, potentially
|    leading to severe congestion of the relays.
`----

This paragraph can be rephrased to say that

a) 6to4 relay routers are needed, and their functions are .....
b) There are two ways to send traffic to a 6to4 relay router.
   1) router may support the anycast address as specified in 6TO4ANYCAST.
   2) contractual agreements.
c) Perils of 1, and 2
d) How to alleviate the perils?

The route optimization method (even if it were to be implemented)
will not alleviate congestion, and may actually increase congestion
in the relay router. e.g. after implementing the route optimization
it might turn out that almost all sites send traffic to a small
subset of relay routers.

If the text is modified, the text corresponding to 6to4 in section
4.1.4 should also be reworded.

Editorial
---------

 1.

,----[ text from unmaneval-00 ]
|    TEREDO is a mechanism designed to provide IPv6 connectivity to hosts
`----

Add reference to TEREDO.

 2.

,----[ text from unmaneval-00 ]
|    An alternative to TEREDO is to simply establish a tunnel to a
|    "tunnel broker" outside the unmanaged network; in order to traverse
|    the NAT, the IPv6 packets would be carried over UDP. This solution
|    was described in a draft that has now expired, and is also mentioned
|    as a possible alternative to the bubble mechanism in the TEREDO
|    specification.
`----

Add normative reference to tunnel broker mechanism, and mention in the
reference that the draft has expired. If the recommendation is followed
then it seems that the draft will be revived.

Also, it will be easy for folks like me who haven't been around for that
long to locate the draft for review purpose.

 3.

At various points, the document talks of a dual-stack ISP. I am not too
sure if this terminology is standard. Can you add a definition of dual-
stack ISP?

 4.

Section titles to be written in upper case.

e.g. s/Meeting case B requirements/Meeting Case B Requirements/

 5.

s/make sure/ensure/

 6.

In section 3.1.1 s/DHCP /DHCPv6 /

 7.

,----[ text from unmaneval-00 ]
|    Several networks have already started using an explicit prefix
|    delegation mechanism using DHCPv6.
`----

Add reference for DHCPv6.

 8.

,----[ text from unmaneval-00 ]
|    * Dynamic configuration using the standard dynamic DNS protocol;
`----

Add reference for the protocol.

Rephrase to

,----[ new text ]
|    * Dynamic configuration using the standard Dynamic DNS (DDNS)
|      protocol;
`----

 9.

,----[ text from unmaneval-00 ]
|    Manual configuration of stable addresses is not satisfactory in an
|    unmanaged IPv6 network: the prefix allocated to the gateway may or
|    may not be stable, and in any case copying long binary addresses
|    through a manual procedure is error prone.
`----

Rephrase to

,----[ new text ]
| Manual configuration of stable addresses may not satisfactory in an
| unmanaged IPv6 network if the prefix allocated to the gateway is not
| stable, and in any case copying long binary addresses through a manual
| procedure is error prone.
`----

10.

,----[ text from unmaneval-00 ]
|    A simplified form of case B occurs is a single host with a global
|    IPv4 address, i.e. with a direct connection to the IPv4 Internet.
|    This host will be able to use the same tunneling mechanisms as a
|    gateway.
`----

s/case B/case A and B/

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 10:32:24 +0200 (EET)

Chirayu,

Thanks for detailed comments.  These and a couple of others should 
help the unmanaged analysis to get updated and moving on track.  
Responding to one issue only:

> The same comment applies to the text in section 3.2.

This has been discussed in the past, and I believe should not be 
substantially changed.

The point is, if we don't require something like this, we'll end up in 
scenarios where you deploy NAT-PT or something similar internal to an 
unmanaged network.  Moreover, if there are some "too sexy" new IPv6 
applications aout there, I'd suppose they're ones that work even 
work through NAT or NAT-PT. And that's not something we'll want.

So, I think it's very reasonable to recommend deploying dual-stack at 
least as long as you don't have v4 nodes to talk to any more.

The other point here is that if some v6 app just proves too sexy to 
resist, such users/nodes will have an incentive to deploy v6 
themselves, not just translation -- and that's what we want.

Do you agree with this?

(If so, wordsmithing is obviously needed to get the message across 
properly.. could you try to reword it?)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings