Hello,
A few comments on this draft; apologies about a very quick read only.
In general I agree with most conclusions in the draft. I don't like site
locals at all, because they're used wrongly. However, I can understand
why people want to use them .. the perceived ease for itself (but making
it more difficult for _others_).
Substantial comments:
Site-Border Node An IPv6 node with interfaces in more
than one site
==> I note that the definion is different from e.g. what Bob Hinden uses
in his drafts; otherwise put, would sl-impact be significantly changed if
there was a subclass of SBN's: those interfacing one site and "no-site".
Some of the complexities of IPv4 NAT are avoided by the fact that
IPv6 SBRs do not translate site-local addresses into global
addresses. Instead, traffic to and from site-local addresses is
dropped at site boundaries, with an appropriate ICMP error message.
and:
SBRs must ensure that site-local traffic is not forwarded outside
of the site. This requires complex processing in the forwarding
engine of an SBR.
This is another situation where some have argued that the
complexity is already required for link-local addresses, but again
that is not completely true. All IPv6 routers will need to check
all forwarded packets to determine if either the source or
destination is link-local. If so, the packet will be discarded and
an ICMP "scope exceeded" error message will be generated.
==> perhaps this ICMP message is a by-product of scoped address
architecture, but sure isn't defined in addrarch or ICMPv3 documents.
Some people have commented that the same problems exist for link-
local addresses, but this is not entirely true. Link-local
addresses can use an existing identifier, the interface ID, as
their qualifier, while site-local addresses require the
configuration of an artificial zone ID. Also, it is not expected
that link-local addresses will be put in the DNS, or passed around
by applications running on multi-link networks.
==> the middle sentence is not accurate. It is typical that many
interfaces have the same link-local interface ID (e.g. tunnel interfaces).
So, to maximize the chance that connections will survive and that
packets will continue to reach their intended destinations when a
MIPv6 node roams, MIPv6 nodes should not configure site-local
addresses and should not use site-local destination addresses,
perhaps even when global addresses are unavailable. This would
require that MIPv6 nodes ignore site-local prefixes in IPv6 router
advertisements, and that a different set of default address
selection rules be used on MIPv6-capable nodes than is currently
defined for other IPv6 nodes.
==> my belief is that in mobile-IP case, it should be enough that MIPv6
nodes ignore all site-local addresses that are not guaranteed to come from
the Home Agent or while at home. Whether there would be problems with
this is another issue.
7.5 Transport Protocol Issues
Some transport protocols, such as SCTP and SIP, involve passing the
==> strictly speaking, is SIP a transport protocol? I thought it uses UDP
throughout.
8.2.1 Benefits for Newly-Connected Sites
When an isolated site gains connectivity to the IPv6 Internet, it
could be useful for nodes to maintain their site-local addresses,
in addition to their new global addresses. This would allow long-
lived connections to remain active, and would prevent cached,
logged or stored IP address information from becoming invalid.
==> IMO, this is relatively questionable benefit. Obtaining Internet
connectivity is a one-time event. Typically this could be considered as a
"flag day" (or flag hour/minute). Whether long-lived site-local
connections survive this even is IMO completely irrelevant.
IPv6 site-local addressing adds significant complexity and cost to
IPv6, and it does not provide sufficient benefit to justify that
cost. Every benefit of site-local addressing can be better
provided by simpler, less problematic, and less expensive
mechanisms.
==> [referring to GUPI-like solutions in above]. I wouldn't go so far as
to say other mechanisms are necessarily "less expensive". It's more of a
question on who pays the cost. App developers, Internet architects,
people trying to figure out how to make routing GUPI work, ISP's operating
routers, etc.etc.
In a perfect world, GUPI would be a nice solution. But alas, we're far
from the perfect world, and making globally routable GUPI's work could be
more work that we could ever imagine, using current architectural
principles.
Editorial:
==> the numbering of chapters usually starts with introduction.
SBRs do not modify addresses in forwarded IP headers, so the use of
IPv6 site-local addresses does not conflict with end-to-end
security or peer-to-peer communication.
==> s/does/do/
provide split DNS service for customers� site-local addresses.
==> fix weird character
This practice has not been
documented, however, and there may be flaws in this approach,
particularly in the presence of Mobile IP, as described in section
7.4
==> s/7.4/7.4./
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
