Bob:
Thank you for your response. I'm pulling up the remaining questions to the
top here. All my questions were about corner cases and "what ifs" - which is
just the result of being a reviewer of a long-implemented specification.
1) I thought the IPv6 LAN was targeted for new mobile networks or sensor
networks. If so, it may be in the future that the wireless connections would
want to change the MTU on a network to increase the ability to change the MTU.
If you're answer is, we'll make the timer adjustment when these technology use
it in this way, this is a fine answer.
2) On, your comment:
I believe what will happen is that the host will use the new MTU in any new
connections it establishes. Existing connections will continue with preview
MTU.
Did I miss this in the draft? Just to sharpen my knowledge of this draft.
3) The question #4 - I was trying to determine what the interaction between the
SEND with an MTU size option, and this update to RFC1918. It appears in the
specification these two functions are interacting. Is this my imagination?
If not, just for my own information - where do I find this in the
specification.
Thanks,
Sue
-----Original Message-----
From: Bob Hinden [mailto:bob(_dot_)hinden(_at_)gmail(_dot_)com]
Sent: Monday, March 6, 2017 8:39 PM
To: Susan Hares
Cc: Bob Hinden; ops-dir(_at_)ietf(_dot_)org; IPv6 List; IETF;
draft-ietf-6man-rfc1981bis(_dot_)all(_at_)ietf(_dot_)org
Subject: Re: Review of draft-ietf-6man-rfc1981bis-04
Hi Sue,
Thanks for the review, comments below.
Bob
Reviewer: Susan Hares
Review result: Has Issues
ack, Steve,Jeffrey, and Bob:
Thank you for taking on this important revision to the document. I
hope my comments help to improve the document so this important change
can ge deployed.
Thanks
I have reviewed this as part of the routing directorate review. This
review should be treated as any IETF LC comments.
Sue Hares
RTG-DIR Review
Status: I have three concern plus editorial nits.
#1 - Concern 1 is technical regarding the interaction with the MTU
option in ND/SEND plus ditorial nits. See the comments below. I am
not an ND/SEND Expert, please have an imoplementer look at the
requirements.
Concern: I cannot tell how this interacts with the ND/SEND protocol in
the following areas below.
1) Neighbor Unreachability Detection is used for all paths between
hosts
and neighboring nodes, including host-to-host, host-to-router, and
router-to-host communication.
If the source node is on the link and the destination node available
through the router, and the router is in the process of sending a
MTU option to increase the size? How does your algorithm work?
I believe what will happen is that the host will use the new MTU in any new
connections it establishes. Existing connections will continue with preview
MTU.
I also note, that this would be a very rare event as most LANs do not
dynamically change their MTU.
Are the packetization layer notified?
Is the original value a stale notification over time?
You indicate it MUST NOT be done in less than 5 minutes, and that
10 minutes is the norm.
Is 10 minutes really the best response time for this particular
case?
Or did I miss something in your draft?
See above.
2) Assume the same situation as #1, but the
router sends an MTU option to decrease the size.
In this case, the router is sending information that
the MTU has changed, but the first indication for the
end system is based on a Packet-too-Big Message after sending.
I think receiving PTB messages would be the likely result for existing
connections. The host would respond by reducing it’s packet size. New
connections would use the new MTU.
As above, this should be a very rare occurrence.
3) For a multicast packet (3000 bytes), assume that the multicast path
reaches two different routers (router-a and router-b). Assume the
on-link MTU is 3500 bytes, but the previous router-A and router-B MTU
is 2500 bytes.
Router-a responds to the packet with 10ms sending a MTU option that
changes the MTU to support this packet. Router-B sends a redirect for
multicast address to Router-A after 30 ms.
What happens to your path calculation?
Is this again, the 5 minutes (minimum) and 10 minute normal to reset
this value.
The host would use the lowest MTU it received and act accordingly. This is
described in the fifth paragraph of Section 3.
4) What happens if the ND process is instantiated by SEND protocol,
and the host does not contain the appropriate certification
information to timely updates?
Again, the host guessing at the appropriate value?
I don’t follow this? Please explain. This seems more about a question about
SEND, and not rfc1981bis.
#2 - Concern 2 - How does SEND's implementation of MTU option.
mitigate or have no effect on this MTU. Is there a recommendation
that should be made in section 6. Again, please ask a SEND expert for
review.
It works the same. SEND secures ND, it still uses ND. The SEND RFC doesn’t
even reference RFC1981.
#3 - Concern 3 - content of document
This document has two parts: protocol requirements and implementation
requirements.
8 paragraphs (1 page) indicates the IPv6 specification and 6 pages
gives the implementation?
Why did this get split in to 2 documents? Even if this was a bis,
document would it not be better to provide minimal specification for
the protocol change and a larger document with implementation
information.
I'm fine with the WG/ADs deciding, this is the way the document has to
go forward -- but the question should be asked.
The working groups intent in doing this bis document was to make a few changes
to fix a problem related to a change in RFC2460bis, remove mention of RH0
because it was deprecated earlier, and a few other small changes. It was not
to do a major rewrite of the document (or as you suggest, split it into two
documents). The alternative was just to file an errata on RFC1981.
This document is very widely implemented. I don’t think splitting the document
into two would improve anything, and very likely create confusion for the
current implementations.
Editorial nits:
#1 nit - section 5.2 page 8, paragraph beginning
Old /Note: if the /
New/Note: If the/
#2 nit - section 5.2 page 9 paragraph begin
Old /Note: even if/
New /Note: Even if/
#3 nit - section 5.3 page 10 paragraph beginning
Old /Note: an implementation/
New/Note: An implementation/
Noted. Thanks.