Hi,
Below are my LC comments on the scoping-arch document.
In general, I think the document is in a pretty good shape, but can be
improved slightly. I think it should be possible to send the document to
the IESG after a revision.
Two major points to note:
- the ICMPv6-bis document is stalled and blocks the progress of this
work as its currently written, and
- in the usage examples section, we should be double careful not to give
an impression that the applications should need to deal with scope
indexes, etc. stuff beyond the address itself. There may be some
disagreement about this in the WG, but getting a neutral rewording for
"application assumptions" seems to be necessary.
substantial
-----------
1) the number of authors is too many (6). No more than 5 is allowed. I'd
suggest removing one, or putting everyone except the current document editor
as only authors and list only one editor of the document.
2) there is some really, really weird text in section 4 about address
scopes:
[1] defines IPv6 addresses with embedded IPv4 addresses as part of
global addresses. Thus, those addresses have global scope, with
regards to the IPv6 scoped address architecture. However, an
implementation may use those addresses as if they had other type of
scopes for convenience. For instance, [7] assigns link-local scope
to IPv4 auto-configuration addresses, and converts those addresses
into IPv4-mapped IPv6 addresses in order for destination address
selection among IPv4 and IPv6 addresses. This would implicitly mean
IPv4-mapped addresses correspondent to IPv4 auto-configuration
addresses have link-local scope. This document does not preclude
such a usage, as long as it is limited within the implementation.
==> that is, there are no "IPv4 auto-configuration" addresses. This
probably tries to refer to DHCP link-local addresses / zeroconf addresses,
but those are actually *very* far from the intent here. Further, note
that the second-last paragraph is not suitably clear about the connection
of the link-local mapped addresses and the equivalent IPv4 addresses.
Also note "in order for destination ...", should be "in order to perform
destination...". This section is probably a result of getting rid of
RFC1918 + site-local scoping, but failing to reword it appropriately.
I'd suggest e.g. something like:
[1] defines IPv6 addresses with embedded IPv4 addresses as part of
global addresses. Thus, those addresses have global scope, with
regards to the IPv6 scoped address architecture. However, an
implementation may use those addresses as if they had other type of
scopes for convenience. For instance, [7] assigns link-local scope
to IPv4 auto-configured link-local addresses (the addresses
from the prefix 169.254/16 [X]), and converts those addresses
into IPv4-mapped IPv6 addresses in order to perform destination address
selection among IPv4 and IPv6 addresses. This would implicitly mean
the IPv4-mapped IPv6 addresses equivalent to the IPv4 link-local
auto-configuration addresses have link-local scope. This document
does not preclude such a usage, as long as it is limited within the
implementation.
.. where [X] is informational reference to:
[9] S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local
Addresses", Work in Progress.
3) I think this statement in section 5 needs to be spelled out a bit more:
Each interface belongs to exactly one zone of each possible scope.
.. that is, this could be read either as it's probably intended ("no
interface must belong to more than one zone"), or as "each interface must
be in a zone of each scope, even if it would have no addresses etc. from
that scope". If the intent is the latter, this needs to be spelled out a
bit more, if the former, a different wording should be used.
4) I'm not sure whether I see the immediate need for the unique subnet
multicast scope assignment, as below:
Furthermore, to avoid the need to perform manual configuration in
most cases, an implementation should, by default, initially assign
zone indices as follows, and only as follows:
[...]
o A unique subnet (multicast "scop" value 3) index for each
interface
==> this seems mostly like a flawed concept anyway, because you don't really
don't have a multicast "subnet" to begin with, because you don't assign
multicast addresses on interfaces anyway. So, I'd consider removing this
automatic default and requiring the subnet scope be configured manually.
5) In the section 7, "sending packets", IMHO it would be useful to actually
describe the process of how the outgoing interface is identified, or refer
to a section describing this (if it's in the default zone, no problem, but
if you have e.g. two link-local interfaces....):
Although identification of an outgoing interface is sufficient to
identify an intended zone (because each interface is attached to no
more than one zone of each scope), that is more specific than desired
in many cases.
6) In the section 9, "Forwarding", I think the text about picking the
destination address zone could be enhanced a bit:
o The zone of the destination address is determined by the scope of
the address and arrival interface of the packet. The next-hop
interface is chosen by looking up the destination address in a
(conceptual) routing table specific to that zone. That routing
table is restricted to refer only to interfaces belonging to that
zone.
==> that is, this does not seem to spell out whether the routing table
could include more than just the interfaces of destination address zone --
i.e., in the case of a global destination address, the "interfaces belonging
to that zone" is a bit confusing :-)
7) In the section 9, "Forwarding", the second rule about sending an ICMP DU
is specified. Has it already been considered whether this applies to
multicast destination addresses as well? In the past, we've been a bit more
hesitant to send replies to the source of multicast packets (e.g. consider
an almost-global multicast scope that leaks and the source would get e.g.
thousands of "beyond the scope" packets..) ?
o After the next-hop interface is chosen, the zone of the source
address is considered. As with the destination address, the zone
of the source address is determined by the scope of the address
and arrival interface of the packet. If transmitting the packet
on the chosen next-hop interface would cause the packet to leave
the zone of the source address, i.e., cross a zone boundary of the
scope of the source address, then the packet is discarded and an
ICMP Destination Unreachable message [4] with Code 2 ("beyond
scope of source address") is sent to the source of the packet.
8) multicast routing in section 10 is rather weak. This is a direct
resolution of switching from unicast site-locals to multicast
organization-local addresses. However, with multicast addresses, it is
appropriate to use the terms "prefixes" to refer to multicast traffic. The
multicast routing is so different from unicast, and the term is not
qualified to convey the intended message here. Some rewording is needed,
maybe express this using (*,G) or (S,G) state creation where the limits are
placed on the group G.
[...]
information on five interfaces. The information exchanged is as
follows (for simplicity, multicast scopes smaller or larger than
organization except global are not considered here):
o Interface 1
* All global prefixes
* All organization prefixes learned from Interfaces 1, 2, and 3
9) I think the EBGP peering example should be removed from section 11.4.
It seems just an
incredibly bad idea to use just link-locals in an IX. This would cause
serious problems e.g. if someone didn't include "next-hop-self" in their
config. Further, this particular problem has already been solved by making
IX-based addressing available through RIR's. So, IMHO, the paragraph should
be removed:
Another example is an EBGP peering. When two IPv6 ISPs establish an
EBGP peering, using a particular ISP's global addresses for the peer
would be unfair, and using their link-local addresses would be better
in a neutral IX. In such a case, link-local addresses should be
specified in a router's configuration file and the link for the
addresses should be disambiguated, since a router usually connects to
multiple links.
10) Similar bad ideas are described in section 11.7, about how to use IPv6
addresses in URL's. The text seems to say that the apps should then strip
the zone index and be able to parse it.. This would imply that apps handling
URL's should be made aware of link-local addresses and the zone index
parsing. This seems like a very, very wrong way to go:
The preferred format for literal IPv6 addresses in URL's are also
defined [9]. When a user types the preferred format for an IPv6 non-
global address whose zone should be explicitly specified, the user
could use the format for the non-global address combined with the
preferred format.
However, the typed URL is often sent on a wire, and it would cause
confusion if an application did not strip the <zone_id> portion
before sending. Also, the format for non-global addresses might
conflict with the URI syntax [10], since the syntax defines the
delimiter character (%') as the escape character.
Hence, this document does not specify how the format for non-global
addresses should be combined with the preferred format for literal
IPv6 addresses. As for the conflict issue with the URI format, it
would be better to wait until the relationship between the preferred
format and the URI syntax is clarified. In fact, the preferred
format for IPv6 literal addresses itself has same kind of conflict.
In any case, it is recommended to use an FQDN instead of a literal
IPv6 address in a URL, whenever an FQDN is available.
==> suggestion either revise the text significantly or add reword the middle
sentence:
However, the typed URL is often sent on a wire, and it would cause
confusion if an application did not strip the <zone_id> portion
before sending. Note that the applications should not need to care
about which kind of addresses they're using, much less parse or strip out
the <zone_id> portion of the address. Also, the format for non-global
addresses might conflict with the URI syntax [10], since the syntax
defines the delimiter character (%') as the escape character.
11) Note that there is a normative reference to the ICMPv6-bis document,
which has been pretty much stalled for the last 2 years or so. This
document cannot be published before ICMPv6-bis is also published. The
ICMPv6-bis seems integral to this specification, so I think the options are
either to revise the text about sending ICMP DU "beyond the scope of source
address" messages (removing it), or kicking off the effort for getting
ICMPv6-bis out of the door:
[4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for
the Internet Protocol Version 6 (IPv6)", Internet Draft draft-
ietf-ipngwg-icmp-v3-02.txt, November 2001.
editorial
---------
Though the current specification [1] defines unicast site-local
addresses, the IPv6 working group decided to deprecate the syntax and
==> s/current/current address architecture/ (to be clear not to confuse with
this spec :-)
The terms link, interface, node, host, and router are defined in [3].
The definitions of unicast address scopes (link-local and global) and
multicast address scopes (interface-local, link-local, etc.) are
contained in [1].
==> I'd try to find a different word than "contained", but that's ~OK as
well.
Two interfaces to the same Ethernet,
==> s/Ethernet/Ethernet link/
o The zone of the new destination address is determined by the scope
of the next address in the Routing Header and arrival interface of
the packet. The next-hop interface is chosen just like the first
bullet of the rules above.
==> reword to something like below, to spell out what the next address was:
(also, add "the" before arrival):
o The zone of the new destination address is determined by the scope
of the next address in the Routing Header (the original destination
address of the received packet) and the arrival interface of
the packet. The next-hop interface is chosen just like the first
bullet of the rules above.
...
Note that it is possible, though generally inadvisable, to use a
Routing Header to convey a non-global address across its associated
zone boundary.
==> I'd be a bit more explicit than this.. the convey in this case means
that a link-local address is encapsulated in the "next address" field but is
not going to be used. Try e.g.:
Note that it is possible, though generally inadvisable, to use a
Routing Header to convey a non-global address across its associated
zone boundary in the previously-used next address field, similar as
one can convey the information in the protocol payloads as well.
(could also omit from "similar.." not sure if that's good..)
...
For example, consider a case where a link-border node
(e.g., a router) receives a packet with the destination being a link-
local address.
==> continute the last sentence like:
local address, and the source address a global address.
Note: since unicast site-local addresses are deprecated, and link-
local addresses does not need routing, the discussion in this section
==> s/does/do/
o Interface 3
* All global prefixes
* All organization prefixes learned from Interface 1, 2, and 3
==> s/Interface/Interfaces/
identify a particular zone of the address' scope. Although a zone
==> s/address'/address's/
When an implementation interprets the format, it should construct the
"full" zone ID, which contains the scope type, from the <zone_id>
part and the scope type specified by the <address> part.
==> unless I have completely misunderstood the spec, the first "scope type"
should actually be "scope zone" :-)
Here is a concrete example. Consider a multi-linked router, called
"R1", that has at least two point-to-point interfaces (links). Each
of the interfaces is connected to another router, called "R2" and
"R3", respectively. Also assume that the point-to-point interfaces
are "unnumbered", that is, they have link-local addresses only.
==> this is an "ipv6-centric" definition of unnumbered. Classically,
unnumbered interfaces have no addresses *at all*. So, I'd use a different
wording than "unnumbered", or maybe "globally unnumbered" would be good
enough even though it sounds odd..
here, since R1 has more than one link and hence the telnet command
cannot detect which link it should try to connect. Instead, we
should type the link-local address with the link index as follows:
==> s/try to connect/try to use for connecting/ !! (one doesn't connect to
a link.. :-)
--
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 IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
