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

Suresh Krishnan <> Wed, 08 March 2017 00:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E90F129516; Tue, 7 Mar 2017 16:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MA-vKLPOZ6e2; Tue, 7 Mar 2017 16:02:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E7E0129489; Tue, 7 Mar 2017 16:02:34 -0800 (PST)
X-AuditID: c6180641-c3fff70000000a06-d5-58bf03c15d30
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 79.ED.02566.1C30FB85; Tue, 7 Mar 2017 20:02:28 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Tue, 7 Mar 2017 19:02:30 -0500
From: Suresh Krishnan <>
To: Susan Hares <>
Subject: Re: Review of draft-ietf-6man-rfc1981bis-04
Thread-Topic: Review of draft-ietf-6man-rfc1981bis-04
Thread-Index: AQHSlQrd5BFYuQiyL06FWZtjocLrOqGI8MuAgAAj+oCAAVN9gA==
Date: Wed, 8 Mar 2017 00:02:30 +0000
Message-ID: <>
References: <> <> <00fb01d296f5$85c57570$91506050$>
In-Reply-To: <00fb01d296f5$85c57570$91506050$>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_A7DE507A-13D0-4DF8-9820-AA1A7A2ED685"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyuXRPgu4R5v0RBjcXCFlsfb+PzeLY2tcs Fs82zmexeHn2PZNFb9MSZos/b16xOLB57Jx1l91jyZKfTB6zX19nDWCO4rJJSc3JLEst0rdL 4MrYeeM+S8Fl64pV0w6xNDDOMu9i5OSQEDCReHPpK1sXIxeHkMB6RonZr/ezQjjLGCXmXZjC AlLFBlS1YednJhBbREBR4sjVdewgRcwCNxklOi4tYQVJCAMVTZsziRmiyFTi5Pqr7BC2k8Tj o5fYQGwWARWJfxePgQ3iFbCXODr9GjvEtrWMEst/32YESXAKmEuc3HwRrIFRQEzi+6k1YA3M AuISt57MZ4K4W0Ti4cXTbBC2qMTLx/9YIWwliTmvrzFDXDeFUWLR5qXMENsEJU7OfMIygVFk FpJZs5DVzUJSB1GkLbFs4WugOAeQrSMxeSEjRNhU4vXRj1C2tcSMXwfZIGxFiSndD9kXMHKs YuQoLS7IyU03MtzECIzHYxJsjjsY9/Z6HmIU4GBU4uHdMGlfhBBrYllxZe4hRhWg1kcbVl9g lGLJy89LVRLhbbfcHyHEm5JYWZValB9fVJqTWnyIUZqDRUmc93rI/XAhgfTEktTs1NSC1CKY LBMHp1QDo8Pm3Ya63+5wTNWKrFkqzHih6VFN26H8JYtFw31Ftp24KXXtWcZnm5YN28yOu2jc u91u8O3tXo6VJ1++3cfxXz/mVgyvXKTEhRf8RnblNX+/l7gIV8UdXRSfJnNjr5XHpSR5PoEt C8ymXHAKdn523oEpJeufuJTuxKtM+455hZ05X2j6U6tMVomlOCPRUIu5qDgRAChfW6HPAgAA
Archived-At: <>
Cc: 6man WG <>, "" <>, Robert Hinden <>, IETF <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Mar 2017 00:02:36 -0000

Hi Sue,
  Thanks for your review. 

> On Mar 6, 2017, at 10:47 PM, Susan Hares <> wrote:
> 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. 

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 interacting.   Is this my imagination?  If not, just for my own information - where do I find this in the specification.   

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.