Hi Brian,
> I'm not sure that it does much, though, to address the issues
> that site-locals raise for transport protocols, applications,
> DNS and management protocols. Am I missing something?
Well, this is the ipv6 working group's mailing list after all. We've
been admonished before for messing around in other group's layers.
But, we are responsible for the impact that our decisions
have on other layers. The impacts on all layers must be
considered in the "costs" associated with an architectural
decision. Also, those other WGs/areas have not shown a lot of
willingness to accept & document the implications of the side-by-side
use of global and site-local addressing, which might make us
re-examine whether or not this is a good architectural construct.
I'm not quite sure how the IETF is suppose to work when one group
is making architectural decisions that will have wide-ranging
implications for other groups. I suppose one possibility is that
the group making the architectural decisions could forge ahead and
trust the IESG to decide whether or not those decisions are reasonable
in the bigger picture... Is that how folks think it should work?
Another possibility is that the group defining the architecture could
take responsibility for its wider implications. I guess I'd prefer
that second choice, but I guess it could also be described as
"messing around in other group's layers"...
But for what it's worth: I'm not aware of any problems scoped addresses
cause for transport protocols, the modifications I had to make to our
TCP implementation were straight-forward and obvious.
TCP and UDP are fairly obvious -- include a zone ID as part of the
connection identification.
Site-locals are more complex for other transport protocols, such
as SCTP, SIP, etc. There is an individual draft out (Steve
Deering was one of the authors) that describes the mechanisms
needed to make SCTP work with site-locals. I don't know if this
has been defined for SIP. Does anyone know?
And, what about non-IETF transport and session layers?
One of the issues is that the impact of site-locals is not limited
to the network layer -- each upper level protocol is impacted
individually.
Most applications
don't pass around addresses in the data stream, and I've already
explained in other email how the few that do can handle the issue.
Right... All of the applications (current and potential future
applications) that are negatively impacted by IPv4 NAT will be
impacted by the use of IPv6 site-local addressing on globally-
attached networks.
I think that we understand what the list is for current applications,
and only a few IETF applications (FTP, DNS, etc.) are impacted.
There are also a lot of non-IETF applications (games, conferencing
software, etc.) that will be impacted. And, unlike the NAT case,
we can't really minimize these impacts through ALGs in the border
routers, so each of these applications will have to deal with IPv6
site-local addressing (if present) separately.
I am more concerned, though, by the potential impact on future
applications. Many people point to NAT as an inhibitor of new
application development and deployment -- will IPv6 site-local
addressing present a similar hurdle?
Others have spoken up with DNS solutions. Plus it is not clear to me
that we need a DNS solution. Even Keith says "DNS should not be a MUST.
not all applications need to use it. Also, DNS is a separate service
from IP. IP should not be thought to be dependent on DNS." Personally,
I think site-locals are a big win even if I only ever look them up in a
hosts file.
Interesting viewpoint... Personally, I think that we will get all
of the costs of site-local addressing and none of the benefits if
we encourage their use on globally-connected networks but don't
figure out a way to get them into the DNS.
Finally, I'm not aware of any problems site-locals cause
for management protocols either.
I think I explained this somewhere else in this thread, but it has
been a long thread, so perhaps I'm misremembering...
Management protocols (like SNMP) generally involve a network
management station that is managing a group of devices. The
management station may or may not be on the same link or in
the same site as the devices that it is managing. So, the
management station may or may not have the context to know
which other host a link-local or site-local address refers to.
We have one example today where the use of link-local addresses
causes a problem for management protocols. IPv6 routing
protocols have been defined to use link-local addresses for
their peers, which means that a management station that downloads
MIB information from a router cannot use the IP addresses in the
MIB to unambiguously identify and/or reach the indicated peers.
Site-local addresses aren't used enough to have caused a problem,
yet. But, their widespread use would cause similar problems in
unambiguously identifying and reaching the other end of a long-
lived connection, for example.
Margaret
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
