Again, thanks for the detailed comments.
>>>>> On Mon, 3 Nov 2003 11:26:55 +0200 (EET),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
> 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.
Sorry, I don't understand the latter suggestion. Could you reword
this one please?
Anyway, I see your point, but I don't have a good idea on how to deal
with this. I don't even know if the "no more than 5" rule must
strictly be applied here (I guess you meant the third paragraph of
Section 2.12(1), draft-rfc-editor-rfc2223bis-07.txt). I'm open to
suggestions from wg.
> 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.
Hmm, it seems that the term "IPv4 auto-configuration" was simply
copied from "[7]" (RFC3484). But in any event, you're correct. The
wording should be revised appropriately.
> 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.
I guess you meant the "second-last sentence" here. And honestly, I
don't see a significant difference between the current text and your
suggestion, but I'm fine with revising the text as suggested.
> 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.
This looks fine, thanks for the suggestion. I'll basically replace
the paragraph with this one, with one exception: we may need to be
consistent about the terms between
- IPv4 auto-configured link-local addresses
and
- IPv4 link-local auto-configuration addresses
I'm not sure if the difference was intentional, but I'll probably be
consistent by using the former one only.
> 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.
Hmm, I think it is Steve who can answer this question with confidence,
but I believe the intention is the latter (including the former one,
of course). For example, I believe the latter intention is more
consistent with Section 6.
I don't know if this is so substantial that we need to revise the
text, but I'll think about it more and try to propose a better wording.
In any event, I think this is rather an editorial issue and does not
cause a significant problem.
> 4) I'm not sure whether I see the immediate need for the unique subnet
> multicast scope assignment, as below:
This one has a follow-up, so I'll answer separately in the follow-up
thread.
> 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.
Sorry, I don't really understand the point...did you mean "how the
outgoing *zone* is identified", not "how the outgoing *interface* is
identified"?
> 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 :-)
Hmm, perhaps I was too familiar with the concept, but I don't see the
problem. In the case of a global destination address, the zone for
the destination address is the single global zone, and the "interfaces
belonging to that zone" are all the interfaces that the receiving node
has. What is confusing here?
> 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..) ?
Ah, good catch. I don't think anyone ever thought this ICMPv6 error
message should be sent against a packet with a multicast destination
address. And, in fact, draft-ietf-ipngwg-icmp-v3-02.txt almost
explicitly prohibits the error message from being sent in this case.
I'll revise the text to make it clear that the error message should be
applied to a packet with a unicast destination address only. (I saw
your second message saying that this is typically a non-issue, which I
agree on. But I also agree that it's better to clarify this point.)
> 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
> not 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.
(in the citation I've corrected the lack of "not" pointed out in your
2nd message)
I see your point. But it seems to me too much to use the term like
(*, G) or (S, G). At least (*, G) is a notion very specific to a
particular type of multicast routing protocols such as PIM-SM.
Isn't it enough to revise the text here using "group" instead of
"prefix(es)"? For example,
say
* All global groups
instead of
* All global prefixes
> 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:
I don't think this is "an incredibly bad idea", but I admit the sense on
this example might be controversial. In addition, I agree on your
second point (this example was written long before the RIR's
introduced IX-based addressing, and has not been revised since then.
This is probably a good timing to revisit it.)
As a conclusion, I agree on removing this example from the document.
> 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:
At least I didn't intend to give an impression that applications need
to parse/strip the format with a zone ID. I see the point, however,
and I'm willing to revise the text if it makes the point clearer.
> ==> 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.
I don't see a problem with the suggested text. Do you think if it is
enough to make the point clear? If so, I'll simply use the rewording.
> 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.
Another good catch. I think you're talking about the rule described
in the 3rd paragraph of draft-rfc-editor-rfc2223bis-07.txt, Section
2.7. Hmm, we have an agenda item on icmp-v3-02 in the 1st ipv6 wg
meeting tomorrow, so for now I'll see what happens on this.
> 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 :-)
Okay. Fixed in my local copy.
> 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.
Hmm, considering poor vocabulary of my own, I'd leave this as is. If
some one can suggest a better wording, I'll use it.
> Two interfaces to the same Ethernet,
> ==> s/Ethernet/Ethernet link/
Okay, fixed.
> 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.
> ...
This "the next address in the Routing Header" should now be in the
destination address of the IPv6 header (swapped with the original
destination address of the received packet). Did you mean "(swapped
with the original destination address of the received packet)"?
Perhaps we can simply say "the next address" (removing "in the Routing
Header").
> 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..)
I don't see the need for the "similar..." part. So I'll revise the
text as follows:
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.
> ...
> 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.
Hmm, not sure if this is a necessary fix, but I'll change the text
as suggested.
> Note: since unicast site-local addresses are deprecated, and link-
> local addresses does not need routing, the discussion in this section
> ==> s/does/do/
Fixed, thanks.
> o Interface 3
> * All global prefixes
> * All organization prefixes learned from Interface 1, 2, and 3
> ==> s/Interface/Interfaces/
Thanks. I also noticed "Interfaces 5" which should be "Interface 5".
Both were fixed in my local copy.
> identify a particular zone of the address' scope. Although a zone
> ==> s/address'/address's/
Changed.
> 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" :-)
I don't think you misunderstand the spec, but the first "scope type"
is correct. It corresponds to the following part of Section 6:
Each zone index of a particular scope should contain an information
to represent the scope type, so that all indices of all scopes are
unique within the node and zone indices themselves can be used for a
dedicated purpose.
So, at least one person read this to mean differently than originally
intended...do we need to be clearer by revising the text?
> 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*.
Correct, and that's why I used double-quotations followed by the
concrete meaning. So, ...
> So, I'd use a different
> wording than "unnumbered", or maybe "globally unnumbered" would be good
> enough even though it sounds odd..
I don't need to revise the text, but we might just remove the
"unnumbered", and say
Also assume that the point-to-point interfaces have link-local
addresses only.
The removal of the possibly confusing word doesn't matter, IMO,
particularly because this is the only occurrence of "unnumbered".
Does this change make sense.
> 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.. :-)
Okay, I don't think "one does connect to a link" is always odd, but I
agree the text in this case is not correct. I'll revise the text as
suggested.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
