Subject: Re: [Int-area] FW: WGLC for draft-atlas-icmp-unnumbered

From: "Alia Atlas" <[email-masked]>
Date: Wed, 10 Sep 2008 17:32:26 -0400

Hi Dave,

Thanks very much for the in depth review!  You've caught a number of things.
Where I don't respond, it is for the minor typos/grammer details - but
that's
because I agree and will take care of them.

In ref to Sec 3.2, you asked:
"Also why does PMTU care about identifying the outgoing interface? As far as
I know it doesn't, it just cares about determining the PMTU. Elaborate or
delete."

The idea here is to learn what interface has the lowest MTU.  For instance,
think of this as an ops tool, which helps discover incorrectly configured
interfaces.

In ref to Sec 4, bullet 4, you asked:
"Comment [DT9]: Is this the ifName as specified by the Interfaces Group MIB
[RFC2863]? If it's not the same as ifName, why not? Section 4.2 partly
answers this but the reader is looking for the answer here due to the
wording of the previous bullet."

I can copy/move the text from 4.2 to here.  There is the option for the text
to be something other than the ifName, if that is desired by the operators.
I see that you are concerned about this by the comment:

"Comment [DT15]: BUG: This can cause problems if the human meaningful name
is the same as the ifName of some other interface. How can you tell whether
it's an ifName or not? Suggest requiring it to be the ifName. If you want
something else, then use a different subobject."

It is a SHOULD; I don't think it needs to be a MUST.  I agree that it would
be possible to configure a different interface's ifName as the string, but
that supposes that there is malicious access to the router for deliberate
confusion.   Do you see this as a likely problem?  I think it is far better
to allow flexibility over the ifName so that operators can get more relevant
data, based on what is desired for their tools.

In ref to Sec 4, bullet 4, you said:
"Comment [DT10]: In general, including this would appear to be a bad thing,
since you'd get less of the original IP packet that triggered the ICMP
error."

The reason there is a limit to 62 bytes is to trade-off between this concern
and getting additional useful information.

In ref to Sec 4.1 and the description of "included information", you said:
"Comment [DT11]: This label doesn't match the diagram above."

It matches the text that breaks the C-type into 2 fields - the "interface
role" and the "included info".  The diagram shows the included
info field broken down further to show the meaning of the bits in the
included info field.   I'll add a level to the diagram explicitly labeling
those 6 bits as "included information".

In ref to Sec 4.1, bit 2 description, you said:
"Comment [DT12]: RFC 2463 states: " (c) If the message is a response to a
message sent to an address that does not belong to the node, the Source
Address should be that unicast address belonging to the node that will be
most helpful in diagnosing the error. For example, if the message is a
response to a packet forwarding action that cannot complete successfully,
the Source Address should be a unicast address belonging to the interface on
which the packet forwarding failed."
Given this, why would an IPv6 address appear in this extension?
Is this so you can put a link-local address in the extension where you have
to pick a global address in the source address? Or what?"

Well, the node can't use both the IPv6 address of the incoming interface and
that of the outgoing interface as the packet's source address.  Thus, the
ability to expressly include the outgoing interface's IPv6 address is
useful.  As you say, it also lets one put the link-local addresses into the
extension, if that's desirable.

In ref to Sec 4.1 description of the bits in the Included Information field,
you said:
"Comment [DT13]: What's the point in having reserved bits that aren't
contiguous? This limits the ability to (say) use a 3-bit field in the
future. Can bit 3 be moved to this position?"

In the original draft, we had a flag for IPv4 address and a different flag
for IPv6 address.  When we consolidated them, rather than moving the flags
around, we just made it reserved.  If there aren't implementations yet that
care and can't easily be changed, then I agree that having the reserved bits
together would be better.  Without express agreement, I'm reluctant to
change.

In ref to Sec 4.1 discussion of the ordering of the information and
sub-objects, you said:
"Comment [DT14]: BUG: Because you "MUST ignore" the reserved bits on
receipt, then in the future if one is used then you will parse the rest
incorrectly. You need to constrain the first sentence of this paragraph to
be just the 3 types of information in this document, and it can be followed
by arbitrary data that MUST be ignored."

Yes - this is a very good point.  The issue is how future additions that use
the reserved bits should be added in.  I think we need to address that here
as well.  Do you have any suggestions?  We could require them to be
sub-objects that indicate their length in the first byte... and place them
after the 3 defined here and in the order of bits?

In ref to sec 4.2, you said:
"Comment [DT16]: The ifIndex is sufficient for cross-correlation and takes
up far less packet space. And since the UTF-8 might not be displayed
correctly or in a language the human reader understands, it can't be relied
upon for human reader familiarity. Hence one could argue that the name is
harmful by comparison to just using ifIndex. Just like traceroute can do
reverse DNS to get the full name based on IP address, it could do SNMP to
get the ifName based on the ifIndex, for routers it has permission to
access."

The interface indicated by an ifIndex can change with rebooting of a router;
there are also dynamic interfaces that come and go.  Having the associated
name is useful there.  Similarly, with traceroute, reverse DNS is usually
done to provide the name for the IP addresses because that gives more
meaning.

As for your concern about UTF-8, the program receiving packets with this
extension will need to be updated to understand and display the information
anyway; I'm sure that UTF-8 compatibility would be included or the name
wouldn't be displayed if that wasn't possible.

I'm not sure I understand your argument about human reader familiarity.
Even if the name is in a different language, it can give some useful
information.  Some of that depends on who is expected to get this extra
info; I can certainly see the name being something that is limited to those
IP addresses associated with that network's operators.

As for your suggestion that every traceroute should also do SNMP to every
hop on the path, well, I would just like you to think about the scaling
concerns if one is probing many paths.  That also assumes that the box doing
the traceroute has access/authority to SNMP to all those routers; it's
entirely likely that would not be the case.

In ref to sec 4.4,
"If the interface in question is unnumbered, then the Interface Information
Object SHOULD include the ifIndex and SHOULD NOT include an IP address."

 you said:
"Comment [DT17]: Huh? Section 4 implies this has to be MUST NOT. To avoid
violating section 4, what IP address could this legally contain?"

I don't have a good suggestion for what address it could legally contain.
I'm willing to make this a MUST NOT, unless I hear disagreement.

Thanks again for the detailed review,
Alia

On Wed, Sep 10, 2008 at 4:02 PM, <[email-masked]> wrote:

>
>
> > -----Original Message-----
> > From: Dave Thaler [mailto:[email-masked]]
> > Sent: Tuesday, September 09, 2008 6:36 PM
> > To: Jari Arkko; Internet Area
> > Cc: [email-masked]; Ron Bonica;
> > [email-masked]; [email-masked]
> > Subject: RE: [Int-area] WGLC for draft-atlas-icmp-unnumbered
> >
> > My comments are in the PDF attached (yeah this makes it hard
> > to respond to in email, but it's the fastest way for me to
> > review in detail and I figure you'd rather have comments now
> > than maybe get them later or maybe not :)
> >
> > I also read draft-watkins-icmptype11code0 and believe it
> > should be merged (i.e., next hop IP address information) into
> > the same document.
> >
> > Because of the technical issues I point out in my review, and
> > the possible combination with the watkins doc, I would
> > suggest another WGLC after the next version of the doc comes out.
> >
> > -Dave
> >
> > ________________________________________
> > From: [email-masked] [[email-masked]]
> > On Behalf Of Jari Arkko [[email-masked]]
> > Sent: Saturday, September 06, 2008 2:48 AM
> > To: Internet Area
> > Cc: [email-masked]; Ron Bonica;
> > [email-masked]; [email-masked]
> > Subject: [Int-area] WGLC for draft-atlas-icmp-unnumbered
> >
> > This is the start of the two week WG last call period for
> > draft-atlas-icmp-unnumered. Please send comments by September
> > 20th, 2008. The intended status of the draft is Proposed Standard.
> >
> > Given that there has been other proposals in this space too
> > and some discussion about what the drafts should contain:
> > please take the intended scope of the document as ICMP
> > extensions useful for retrieving more interface and next-hop
> > related information in a traceroute/error situation. That is,
> > please consider whether functionality defined in
> > draft-watkins-icmptype11code0 is also something that should
> > be defined.
> > I only want to progress one document on this, however (or at
> > least coordinate the formats).
> >
> > Jari
> >
> > _______________________________________________
> > Int-area mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/int-area
> >
>
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area