Subject: unamanged solutions comments

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Sep 2002 18:35:22 +0300 (EEST)

2.1	Evaluation of connectivity mechanisms

==> this needs to reworded or split: many of these are IMO not strictly
speaking connectivity mechanisms

2.1.2	6to4
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 [RFC3056], 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.

==> There are two problems with relays:
 1) configuring the relay on 6to4 router; anycast address helps a bit there.
 2) v6 nodes finding the closest relay advertising 2002::/16.  This is not
addressed here, and I think is a major problem: there is zero guarantee
about how unoptimal the return path is (you can make some assumption about
the forward path, to the 6to4 relay close to you)!

2.1.6	SIIT

Stateless IP/ICMP Translation Algorithm (SIIT) is a generic
translation mechanism between IPv4 and IPv6. The main
characteristics of DSTM are as follow:

==> s/DSTM/SIIT/

2.1.7	NAT-PT

particular, the specification discusses a DNS ALG that would enable
the NAT-PT system to reply with a "translated" record, e.g. a AAAA
record contained the IPv6-mapped IPv4 address of an IPv4 only host,
or a A record containing the IPv4 address statically assigned to an
IPv6 only host.

==> mapped address is NAT64 semantic, not NAT-PT.

2.1.10	DSTM

DSTM may have a role to play in the transition of large network, or
in that of ISP networks, but its role in the transition of unmanaged
networks is thus marginal at best: it does not support IPv6 only
hosts, and it does not provide an operational advantage in the
unmanaged network.

==> Some generalized form of DSTM could be implemented in case D
(e.g. gateway performing DSTM tunneling function and providing v4 to the
local v4-only nodes)

3.1.3	MDNS

-- discussion of [MDNS] --

==> I'm not sure how LLMNR is all that applicable (at best, if there's a
disconnected site scenario).

3.1.6	Reverse lookup wildcard

1234:5678:9ABC::1 by providing a pointer to either "1234-5678-9ABC-
0-0-0-0-1.example.net", or "1234-5678-9ABC-0-0-0-0-
1.foo.example.net" - i.e. with or without an identification of the
client's account in the pointed name. Privacy advocates will
probably insist that ISP do not include client identification in
such pointers, as this would negate all benefits of privacy
addresses.

==> or e.g. 0-0-0-0-1.foo.example.net.
==> "foo" is unlikely a clearly identifiable (like a surname) so "foo" or
the prefix (assuming it's static) will reveal the same thing anyway.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Bill Owens <[email-masked]>
Date: Thu, 19 Sep 2002 16:19:32 -0400

>the forward path, to the 6to4 relay close to you)!

It strikes me that no tunneled infrastructure (automatic or manual 
setup) is likely to grow dense enough to provide really good 
performance, at least not without becoming unmanageable in its 
complexity. I have always regarded that as a fundamental tradeoff 
when using tunnels for anything, not just IPv6.

6to4 at least has the advantage of providing good pairwise 
connectivity between 6to4 routers, something that is not always the 
case with manually configured tunnels.

Bill.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Sep 2002 23:33:01 +0300 (EEST)

> when using tunnels for anything, not just IPv6.

I'd perhaps reword that as "no global tunneled infrastructure".  And even 
then I'd be a bit hesistant: tunneling across short distances is not that 
big a deal, but adding different administrative parties can make it more 
and more difficult.

Solutions like ISATAP can provide rather good performance in a limited
case;  connections outside of the "site" could be native v6.

---

From: Bill Owens <[email-masked]>
Date: Thu, 19 Sep 2002 16:52:41 -0400

>case;  connections outside of the "site" could be native v6.

That's a good point. I'm thinking of the global IPv6 infrastructure 
and individual hosts or sites connecting to it. And I suspect that 
any solution for this case that uses tunnels, automatic or manual, is 
likely to face the problem of sub-optimal forward and/or reverse 
paths that you mentioned originally. In other words 6to4 is neither 
better nor worse, just different.

As long as the density of tunnels is much less than the density of 
the connections in the underlying network, the path taken by the 
tunneled traffic between two points will be likely to be worse than 
the path taken by native traffic. And the well-known scaling problems 
of tunnels (including crossing administrative domains) makes it 
unlikely that they will become very dense without suffering 
maintainability problems.

Since there are relatively few 6to4 relay routers out there, 
performance is often poor for 6to4 to native traffic. But the same is 
often true for tunnel brokers, and sometimes for manual tunnels. And 
at least 6to4 has good performance to other 6to4 sites.

Bill.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 19 Sep 2002 17:16:39 -0400

-- jeudi, septembre 19, 2002 16:52:41 -0400 Bill Owens <[email-masked]> 
wrote/a écrit:

> That's a good point. I'm thinking of the global IPv6 infrastructure and
> individual hosts or sites connecting to it. And I suspect that any
> solution for this case that uses tunnels, automatic or manual, is likely
> to face the problem of sub-optimal forward and/or reverse paths that you
> mentioned originally. In other words 6to4 is neither better nor worse,
> just different.

automatic tunnels techniques usually mean (by design) that the path is not 
"controlled".

>
> As long as the density of tunnels is much less than the density of the
> connections in the underlying network, the path taken by the tunneled
> traffic between two points will be likely to be worse than the path taken
> by native traffic. And the well-known scaling problems of tunnels
> (including crossing administrative domains) makes it unlikely that they
> will become very dense without suffering maintainability problems.
>
> Since there are relatively few 6to4 relay routers out there, performance
> is often poor for 6to4 to native traffic. But the same is often true for
> tunnel brokers, and sometimes for manual tunnels. And at least 6to4 has
> good performance to other 6to4 sites.

semi-automatic tunnels techniques like tunnel brokers can be deployed so 
that it does have less sub-optimal forward/reverse paths. It depends on 
where/how you deploy them. If they are near to you, network topologically 
speaking, then the sub-optimal paths might be not that a problem.

Marc.

------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Thu, 19 Sep 2002 15:54:09 -0700 (PDT)

I should probably comment on this, since I've spent some time thinking
about the subject recently:

> automatic tunnels techniques usually mean (by design) that the path is not 

In the case of ISATAP, "control" is provided by the site security recommendations
in the base document. If a particular deployment perceives a need, stronger degrees
of control might be possible by fusing end-to-end (or, end-to-edge) mechanisms with
the ISATAP base specification. This would result in a "semi-automatic-automatic"
tunnel; cumbersome wording, but still a useful mechanism.  

> speaking, then the sub-optimal paths might be not that a problem.

This is never a problem with automatic tunnels (even when they are
"semi-automatic-automatic"); route optimization is enabled by default.

Fred
[email-masked]

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 19 Sep 2002 19:09:42 -0400

-- jeudi, septembre 19, 2002 15:54:09 -0700 Fred Templin 
<[email-masked]> wrote/a écrit:

>> automatic tunnels techniques usually mean (by design) that the path is
>> not  "controlled".
>
> In the case of ISATAP, "control" is provided by the site security
> recommendations in the base document. If a particular deployment
> perceives a need, stronger degrees of control might be possible by fusing
> end-to-end (or, end-to-edge) mechanisms with the ISATAP base
> specification. This would result in a "semi-automatic-automatic" tunnel;
> cumbersome wording, but still a useful mechanism.

agreed. my statement was generic, knowing that there are many variations of 
this.

>> where/how you deploy them. If they are near to you, network
>> topologically  speaking, then the sub-optimal paths might be not that a
>> problem.
>

some automatic tunnels are not so much route optimized:
just one example: 6to4 user, sending a packet to 2001:.. through some 6to4 
relay. the reverse path could be very different...

Marc.

---

From: Fred Templin <[email-masked]>
Date: Thu, 19 Sep 2002 16:32:11 -0700 (PDT)

> relay. the reverse path could be very different...

I would view this as asymmetric paths in the forward and reverse directions.
But, you are right that true shortest-path routing may not occur in one
or both of the directions.

Fred
[email-masked]

---

From: [email-masked]
Date: Thu, 19 Sep 2002 23:27:30 -0400 (EDT)

> automatic tunnels techniques usually mean (by design) that the path is not 

Perhaps I'm misunderstanding you, but I would expect that any tunnel
between the same two endpoints would follow the same underlying path,
regardless of how it was set up. Everything is driven by the destination
IPv4 address, after all. Unless you have some sort of traffic engineering
going on, but that's always an exception case.
 
And although automatic tunnels don't usually allow you to control the
path, they should select the best possible path based on whatever IPv4
metrics you use, so you probably don't care to be involved ;)

> speaking, then the sub-optimal paths might be not that a problem.

I think we're agreeing on the general point that if we use a tunnel
protocol that depends on fixed relays/brokers/servers, having more of them
is better because the odds are that one will be closer to you, and (if the
path is asymmetric, as it is for 6to4 relays) one will also be closer to
the other end. Or are you saying that something else can be done to
improve the situation, without increasing the number of relays?

I am making some underlying assumptions for relays, that they will in some
reasonable fashion connect to the native infrastructure, and further that
the native infrastructure will perform well (though perhaps not as well as
the equivalent IPv4 path). Someone who has a marginal connection to the
'core' of the native IPv6 network (wherever that is) probably won't help
matters by running a relay.

In a semi-utopia, we'd have everyone who is able to connect to the native
IPv6 network doing so, have all our manual tunnels following the best IPv4
paths to the native infrastructure, and have lots of
relays/brokers/servers well connected to both IPv4 and IPv6. I'm working
on all those angles, at least in my little corner of the network ;)

Bill.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 24 Sep 2002 18:06:28 +0200

> going on, but that's always an exception case.

During the lifetime of a tunnel the underlaying path can change due to 
policy or failures (or even restorations), without it affecting the 
functionality of the tunnel as that is based on the IPv4 end-point, 
just as you point out.

Best regards,

- kurtis -