Subject: Review of draft-ietf-6man-rfc1981bis-04

From: Susan Hares <[email-masked]>
Date: Sat, 04 Mar 2017 09:14:50 -0800

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. 

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? 
   
   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? 

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. 

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. 

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? 

#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. 

#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. 

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/

---

From: Bob Hinden <[email-masked]>
Date: Mon, 6 Mar 2017 17:38:33 -0800

Hi Sue,

Thanks for the review, comments below.

Bob

> hope my comments help to improve the document so this important change

Thanks

>   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.

>   Or did I miss something in your draft?

See above.

>   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.

> Is this again, the 5 minutes (minimum) and 10 minute normal to

The host would use the lowest MTU it received and act accordingly.  This is described in the fifth paragraph of Section 3.

> 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.

> that should be made in section 6.  Again, please ask a SEND expert

It works the same.  SEND secures ND, it still uses ND.   The SEND RFC doesn’t even reference RFC1981.

> 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.

> New/Note: An implementation/

Noted.  Thanks.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Mar 2017 22:47:19 -0500

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. 

> 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:[email-masked]] 
Sent: Monday, March 6, 2017 8:39 PM
To: Susan Hares
Cc: Bob Hinden; [email-masked]; IPv6 List; IETF; [email-masked]
Subject: Re: Review of draft-ietf-6man-rfc1981bis-04

Hi Sue,

Bob

Thanks

> 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.
> 
>   If the source node is on the link and the destination node available

See above.

> 
> 
> 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.
> 
> Is this again, the 5 minutes (minimum) and 10 minute normal to reset 
> this value.

> 
> 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?
> 

> that should be made in section 6.  Again, please ask a SEND expert for 
> review.

> document would it not be better to provide minimal specification for 
> the protocol change and a larger document with implementation 
> information.
> 

Noted.  Thanks.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Mar 2017 00:02:30 +0000

Hi Sue,
  Thanks for your review. 

> On Mar 6, 2017, at 10:47 PM, Susan Hares <[email-masked]> wrote:
> 
> Bob: 
> 

The mobile and sensor networks you talk about can independently increase the MTU on the access link to which the host initiating PMTUD connects to. While this will affect the assumed initial value of the PMTU, it may or may not affect the final PMTU. If the first hop link was the link with the smallest MTU on the path, increasing it would have an effect on the PMTU. Else, it will not. 

> 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 i…

The SEND MTU option (which is the same as the ND MTU option - type 5) is used just to communicate the MTU of the local link. There is no real interaction between this and PMTUD except for the fact that the Path MTU cannot exceed this number.

Thanks
Suresh