Subject: [OSPF] What is the use of MTU field in DD packet

From: "Prasanna Kumar A.S" <[email-masked]>
Date: Wed, 28 May 2008 17:48:15 +0530

Hi
  I just wanted to understand what the primary use of exchanging MTU in
DD packets and doing MTU-check is? Is it only for the control plane or
is it for the DATA-plane?

Why I am getting this doubt is, in draft-ietf-ospf-af-alt-06.txt doesn't
specify which MTU we should use while exchanging the DD packet for the
ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or
ipv4-mtu?

Regards
Prasanna 
_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2008 08:24:07 -0400

Hi Prasanna,

> is it for the DATA-plane?

Control-plane - when sending DD, LSR, and LSU packets, OSPF will  
attempt to send as many LSA headers or complete LSAs as will fit in a  
maximum sized packet.

> ipv4-unicast or ipv4-mutlticast Address-family, is it ipv6-mtu or

We have this clarified in the an update which we post soon. Since  
this is OSPFv3 which using IPv6 for transport, you always use the  
IPv6 MTU.

Thanks,
Acee

---

From: Paul Wells <[email-masked]>
Date: Wed, 28 May 2008 13:05:02 -0500

Hi Acee,

I disagree about the "original intent" of the MTU field. As I see 
it, it's function is to prevent an OSPF adjacency from forming 
over a link where the endpoints disagree about the link MTU. We do 
this primarily to prevent the data plane from using a link that 
will drop packets sent to a system with an MTU smaller than ours.

While OSPFv3 certainly needs to know the IPv6 link MTU when 
building it's packets, this information should be available 
locally without reference to the MTU field in the DBD packet.

So, I would argue that in af-alt the MTU in the DBD packet should 
be for the address family we are routing, not IPv6 in all cases.

Regards,
Paul

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2008 14:51:43 -0400

Hi Paul,

On May 28, 2008, at 2:05 PM, Paul Wells wrote:

> it, it's function is to prevent an OSPF adjacency from forming over  
> a link where the endpoints disagree about the link MTU. We do this  
> primarily to prevent the data plane from using a link that will  
> drop packets sent to a system with an MTU smaller than ours.

I happen to remember the discussion of this problem on the OSPF list  
and this was not the primary motivation. There were lots of problems  
with bridged heterogeneous LANs with mismatched MTUs (ethernet, FDDI,  
token ring, and the worst of all technologies - ATM emulated  
LANs :^).  Adjacencies would come up fine initially but the exchange  
process would hang indefinitely when they were restarted due to the  
router with the larger MTU having a larger database and trying to use  
full DD packets. Unfortunately, the OSPF list was hosted on a server  
at Microsoft Corporation in those days and I don't have access to  
archives. Here is some text from RFC 2178, appendix G:

G.9 Detecting interface MTU mismatches

    When two neighboring routers have a different interface MTU for  
their
    common network segment, serious problems can ensue: large packets  
are
    prevented from being successfully transferred from one router to the
    other, impairing OSPF's flooding algorithm and possibly creating
    "black holes" for user data traffic.

    This memo provides a fix for the interface MTU mismatch problem by
    advertising the interface MTU in Database Description packets.  
When a
    router receives a Database description packet advertising an MTU
    larger than the router can receive, the router drops the Database
    Description packet. This prevents an adjacency from forming, telling
    OSPF flooding and user data traffic to avoid the connection between
    the two routers. For more information, see Sections 10.6, 10.8, and
    A.3.3.

On the other hand, once the MTU checking was implemented, I believe  
data plane MTU consistency has been purported as a benefit. If we  
used the IPv4 MTU in the IPv4 address database exchanges, we could  
still have an IPv6 MTU mismatch. One could depend on the unicast IPv6  
address family for this checking but, heretofore, we've kept the  
instances independent.

Thanks,
Acee

> building it's packets, this information should be available locally  
> without reference to the MTU field in the DBD packet.
>
>> attempt to send as many LSA headers or complete LSAs as will fit  
>> in a  maximum sized packet.

---

From: Paul Wells <[email-masked]>
Date: Wed, 28 May 2008 16:31:27 -0500

Hi Acee,

That was before my time, so I'll defer to your recollection about 
how OSPF MTU checking came to be. The section of 2178 below does 
seem to give equal weight to both the control and data plane 
benefits of MTU verification however.

This still leaves the question of what to do for af-alt when 
routing address families other than IPv6. It seems that there are 
two cases of interest in deciding which MTU to advertise in the 
DBD packets:

1. IPv6 MTUs match, but IPv4 MTUs differ.
2. IPv6 MTUs differ, but IPv4 MTUs match.

In the first case I don't think we're doing anyone a favor by 
installing routes in the IPv4 RIB that will be unreliable due to a 
MTU mismatch.

In the second case OSPFv3 flooding and synchronization may be 
compromised. A side effect of this may be that the adjacency never 
forms, or having formed may later fail.

Short of resorting to LLS or some other way of communicating both 
MTUs it seems we have to pick one or the other.

I'd like to propose that we use the DBD packet to communicate the 
IPv4 MTU when routing that address family, and use the IPv6 
minimum MTU of 1280 bytes for OSPFv3 protocol packets.

Thanks,
Paul

Acee Lindem wrote:
>> I disagree about the "original intent" of the MTU field. As I see it, 
>> it's function is to prevent an OSPF adjacency from forming over a link 
>> where the endpoints disagree about the link MTU. We do this primarily 
>> to prevent the data plane from using a link that will drop packets 
>> sent to a system with an MTU smaller than ours.
> 
> I happen to remember the discussion of this problem on the OSPF list and 
> this was not the primary motivation. There were lots of problems with 
> bridged heterogeneous LANs with mismatched MTUs (ethernet, FDDI, token 
> ring, and the worst of all technologies - ATM emulated LANs :^). 
>  Adjacencies would come up fine initially but the exchange process would 
> hang indefinitely when they were restarted due to the router with the 
> larger MTU having a larger database and trying to use full DD packets. 
> Unfortunately, the OSPF list was hosted on a server at Microsoft 
> Corporation in those days and I don't have access to archives. Here is 
> some text from RFC 2178, appendix G: 
> 
>    When two neighboring routers have a different interface MTU for their
>    common network segment, serious problems can ensue: large packets are
>    advertising the interface MTU in Database Description packets. When a
> On the other hand, once the MTU checking was implemented, I believe data 
> plane MTU consistency has been purported as a benefit. If we used the 
> IPv4 MTU in the IPv4 address database exchanges, we could still have an 
> IPv6 MTU mismatch. One could depend on the unicast IPv6 address family 
> for this checking but, heretofore, we've kept the instances independent. 
> 
> Thanks,
> Acee
> 
> 
>>
>> While OSPFv3 certainly needs to know the IPv6 link MTU when building 
>> it's packets, this information should be available locally without 
>> reference to the MTU field in the DBD packet.
>>
>> So, I would argue that in af-alt the MTU in the DBD packet should be 
>> for the address family we are routing, not IPv6 in all cases.
>>
>> Regards,
>> Paul
>>
>> Acee Lindem wrote:
>>> Hi Prasanna,
>>> attempt to send as many LSA headers or complete LSAs as will fit in 
>>> a  maximum sized packet.
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2008 18:22:28 -0400

Hi Paul,

> benefits of MTU verification however.

Hey - wouldn't you take credit? It beats the hell out of padding your  
hello packets to the maximum transmission unit (MTU) :^)

> two cases of interest in deciding which MTU to advertise in the DBD  
> packets:
>
> IPv4 MTU when routing that address family, and use the IPv6 minimum  
> MTU of 1280 bytes for OSPFv3 protocol packets.

This is a coherent proposal. I'd like to bounce this off the other  
authors and would solicit general comments. The question is whether  
the OSPFv3 protocol checking for MTU mismatches is worth relegated  
OSPFv3 exchange and flooding to the the IPv6 minimum MTU. I'm not  
sure it does but I'd like to open it up to a brief discussion.

Thanks,
Acee

>>> over a link where the endpoints disagree about the link MTU. We  
>>> do this primarily to prevent the data plane from using a link  
>>> that will drop packets sent to a system with an MTU smaller than  
>>> ours.
>> I happen to remember the discussion of this problem on the OSPF  
>> list and this was not the primary motivation. There were lots of  
>> problems with bridged heterogeneous LANs with mismatched MTUs  
>> (ethernet, FDDI, token ring, and the worst of all technologies -  
>> ATM emulated LANs :^).  Adjacencies would come up fine initially  
>> but the exchange process would hang indefinitely when they were  
>> restarted due to the router with the larger MTU having a larger  
>> database and trying to use full DD packets. Unfortunately, the  
>> OSPF list was hosted on a server at Microsoft Corporation in those  
>> days and I don't have access to archives. Here is some text from  
>> RFC 2178, appendix G: G.9 Detecting interface MTU mismatches
>> On the other hand, once the MTU checking was implemented, I  
>> believe data plane MTU consistency has been purported as a  
>> benefit. If we used the IPv4 MTU in the IPv4 address database  
>> exchanges, we could still have an IPv6 MTU mismatch. One could  
>> depend on the unicast IPv6 address family for this checking but,  
>> heretofore, we've kept the instances independent. Thanks,
>> Acee
>>>
>>>> Control-plane - when sending DD, LSR, and LSU packets, OSPF  
>>>> will  attempt to send as many LSA headers or complete LSAs as  
>>>> will fit in a  maximum sized packet.
>>>> We have this clarified in the an update which we post soon.  
>>>> Since  this is OSPFv3 which using IPv6 for transport, you always  
>>>> use the  IPv6 MTU.
>>>> Thanks,
>>>> Acee
>>>>>
>>>>> Regards
>>>>> Prasanna

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2008 19:17:18 -0400

Hi Michael,

Nope - it was a pre-RFC 2178 thread involving Derek Yeung, John Moy,  
and others.

Thanks,
Acee

On May 28, 2008, at 6:20 PM, Michael Rozhavsky wrote:

>> list and
>> this was not the primary motivation.
>
> I believe this is the discussion you are referring to:
>
> http://marc.info/?l=ms-ospf&m=103430314528492&w=4
>
>> There were lots of problems with
>> Corporation in those days and I don't have access to archives.  
>> Here is some
>> text from RFC 2178, appendix G:
>>
>
> --
>     Michael Rozhavsky

---

From: "Sina Mirtorabi" <[email-masked]>
Date: Wed, 28 May 2008 19:11:55 -0700

Hi Acee,

> minimum  

One issue is backward compatibility, if there is any implementation of
alt draft, then we cannot just change the MTU in the DD packet from IPv6
to IPv4 MTU. If we don't worry about backward compatibility (no deployed
implementation) then we have a shot to define as appropriate. There are
couple of options

1) Paul's proposal however I would add that IPv6 Path MTU discovery
should be used.

2) We can set a bit in the DD packet to indicate that the MTU value is
for both v4 and v6, if this bit is clear (i.e. MTU mismatch between v4
and v6) then the MTU field in DD packet is for corresponding AF, e.g.
IPv4 and for IPv6 mtu we have to use 1) (minimum MTU), the advantage of
this is that unless MTU is really different between v4 and v6 you don't
blindly reduce the IPv6 mtu

3) carry the MTU value for both IPv6 and IPv4 either in DD packet (there
are unused octet although not contiguous block) or through LLS.

4) any other options

The advantage of 2) a part from simplicity is that by not knowing the
IPv6 MTU we fall back to minimum MTU and adj will be formed, for 3) if
there is a MTU mismatch then unless you change the rule and state that
in case of mismatch, default minimum MTU should be used, the adj will
not be established if we follow the MTU mismatch rule. The only
advantage of the 3) compared to 2) is that in case IPv4 and IPv6 does
not match AND IPv6 are the same between the system, the actual IPv6 MTU
(which is carried) is used instead of Minimum MTU. 

thanks
Sina

> >>    the two routers. For more information, see Sections 
> 10.6, 10.8,  
> >> and
> >>    A.3.3.

---

From: "Prasanna Kumar A.S" <[email-masked]>
Date: Thu, 29 May 2008 12:33:50 +0530

Hi
   I suggest following mechanism to communicate both the MTUs
   Initial DD packet should carry the MTU of Address-family which should
match with the mtu of that address-family otherwise mtu check should
fail, (I.e. if initial DD packet with AF bit set and matching MTU then
MTU check should pass) 

and subsequent DD packets should carry the ipv6-MTU (ignore MTU check
for non initial DD packet with Af bit set), And the ipv6 MTU of each
neighbor should be saved in the neighbor data-structure, then smallest
MTU of all the neighbors on the link is used for constructing the
ospf-packets to be transmitted on that link

Regards
Prasanna 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sina Mirtorabi
Sent: Thursday, May 29, 2008 7:42 AM
To: Acee Lindem; Paul Wells
Cc: OSPF List
Subject: Re: [OSPF] What is the use of MTU field in DD packet

Hi Acee,

4) any other options

thanks
Sina

---

From: "Prasanna Kumar A.S" <[email-masked]>
Date: Thu, 29 May 2008 14:13:12 +0530

I second paul, What is the use of the routes learnt when we know
forwarding is going to fail, And secondly the forwarding will fail
selectively only for the large data-packets that makes the
troubleshooting more difficult

Regards
Prasanna 

-----Original Message-----
From: Paul Wells [mailto:[email-masked]] 
Sent: Thursday, May 29, 2008 3:01 AM
To: Acee Lindem
Cc: Prasanna Kumar A.S; OSPF List
Subject: Re: [OSPF] What is the use of MTU field in DD packet

Hi Acee,

Thanks,
Paul

and 

their
are
> On the other hand, once the MTU checking was implemented, I believe
data

---

From: Acee Lindem <[email-masked]>
Date: Thu, 29 May 2008 10:04:50 -0400

Hi Sina,
Other than it will be a pain to specify, I like #2 with one  
variation. I say that if the new bit is clear, the 2 MTUs are equal  
and the specified MTU is simply checked against both MTUs. If it is  
set, it means the MTUs differ and we need to use the IPv6 minimum for  
OSPFv3 packet computation. As someone may point out, it's actually  
more complex - I'll post proposed text (hopefully, later today).
Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 29 May 2008 10:13:21 -0400

Prasanna,

I'm not that keen on using the same field for different purposes. I  
would hope that in most cases the MTUs would be the same anyway.
Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 29 May 2008 14:24:24 -0400

Those of you who have worked with me in the past will not be  
surprised that I have come up with a slightly different solution.  
However, I think this is a simpler approach allows an OSPFv3 router  
to disable IPv6 MTU checking for non-IPv6 address families even if  
their IPv6 MTU matches their IPv4 MTU.

2.7.  Database Description Maximum Transmissoin Unit (MTU)
       Specification for Non-IPv6 AFs

    For address families other than IPv6, both the MTU for the address
    family of the instance and IPv6 MTU used for OSPFv3 maximum packet
    determination must be considered.  The MTU in the Database
    Description packet MUST always contain the MTU corresponding to the
    advertised address family.  For example, if the instance corresponds
    to an IPv4 address family, the IPv4 MTU for the interface MUST be
    specified in the interface MTU field.  As specified section 10.6 of
    [OSPFV2], the Database Description packet will be rejected if the  
MTU
    is greater than the receiving interface's MTU for the address family
    corresponding to the instance.  This behavior will assure an
    adjacency is not formed and address family specific routes are not
    installed over a path with conflicting MTUs.

    The value used for OSPFv3 maximum packet size determination must  
also
    be compatible an adjacency to be established.  Since only a single
    MTU field is specified, the M6-bit is defined by this specification.
    If the M6-bit is set, the OSPFv3 router will send OSPFv3 packets no
    larger than 1280 octets, the minimum IPv6 MTU (refer to [IPV6]).  If
    the M6-bit is clear, the specified MTU should also be checked  
against
    the IPv6 MTU and the Database Description packet should be rejected
    if the MTU is larger than the receiving interface's IPv6 MTU.  If  
the
    IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6
    address families.

    If the M6-bit is set in a received Database Description packet for a
    non-IPv6 address family, the receiving router MUST NOT check the
    Interface MTU in the Database Exchange packet against the receiving
    interface's IPv6 MTU.

    The figure below graphically depicts the OSPFv3 Database Packet:

       0                   1                   2                    3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7  8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
      |      3        |       2       |        Packet  
Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
      |                           Router  
ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
      |                             Area  
ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
      |           Checksum            |  Instance ID  |       
0          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
      |       0       |                
Options                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
      |        Interface MTU          |      0        |0|0|0|M6|0|I|M| 
MS|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
      |                    DD sequence  
number                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
       
|                                                                 |
       
+-                                                               -+
       
|                                                                 |
      +-                     An LSA  
Header                             -+
       
|                                                                 |
       
+-                                                               -+
       
|                                                                 |
       
+-                                                               -+
       
|                                                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+- 
+--+
       
|                       ...                                       |

                  The OSPFv3 Database Description Packet

    The changed fields in the Database Description packet are described
    below.  The remaining fields are unchanged from [OSPFV3].

    Interface MTU
       The size in octets of the largest address-family specific  
datagram
       that can be sent out the associated interface without
       fragmentation.  The MTUs of common Internet link types can be
       found in Table 7-1 of [MTUDISC].  Interface MTU should be set  
to 0
       in Database Description packets sent over virtual links.

    M6-bit
       The Minimum IPv6 MTU bit - this bit indicates the sender wishes
       that the minumum IPv6 MTU be used for OSPFv3 maximum packet size
       determination.

Thanks,
Acee

---

From: Paul Wells <[email-masked]>
Date: Thu, 29 May 2008 14:59:45 -0500

Hi Acee,

This scheme looks okay to me. I have a couple of 
questions/suggestions, though. You say:

"If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for 
non-IPv6 address families."

Do we also need to add a sentence like:

If the IPv6 and IPv4 MTUs are the same, the M6-bit MUST NOT be set 
for non-IPv6 address families.

in order to preclude an implementation setting the M6-bit in all 
cases?

Also, what happens when the M6-bits of routers on the link don't 
match? The text specifies that the router which has differing 
IPv4/IPv6 MTUs will send 1280 byte OSPFv3 packets, but it's really 
the other router(s) on the link that need to do this because they 
don't know what that router's IPv6 MTU is. I'd suggest changing 
the third paragraph to something like:

If the M6-bit is set in a received Database Description packet for 
a non-IPv6 address family, the receiving router MUST NOT check the 
Interface MTU in the Database Exchange packet against the 
receiving interface's IPv6 MTU and it MUST send OSPFv3 packets no 
larger than 1280 octets.

Thanks,
Paul

Acee Lindem wrote:
> Those of you who have worked with me in the past will not be surprised 
> that I have come up with a slightly different solution. However, I think 
> this is a simpler approach allows an OSPFv3 router to disable IPv6 MTU 
> checking for non-IPv6 address families even if their IPv6 MTU matches 
> their IPv4 MTU. 
> 
> 
>    [OSPFV2], the Database Description packet will be rejected if the MTU
>    The value used for OSPFv3 maximum packet size determination must also
>    the M6-bit is clear, the specified MTU should also be checked against
>    if the MTU is larger than the receiving interface's IPv6 MTU.  If the
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |      3        |       2       |        Packet Length            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |                           Router ID                             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |                             Area ID                             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |           Checksum            |  Instance ID  |      0          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |       0       |               Options                           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |        Interface MTU          |      0        |0|0|0|M6|0|I|M|MS|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |                    DD sequence number                           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |                                                                 |
>      +-                                                               -+
>      |                                                                 |
>      +-                     An LSA Header                             -+
>      |                                                                 |
>      +-                                                               -+
>      |                                                                 |
>      +-                                                               -+
>      |                                                                 |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
>      |                       ...                                       |
> 
>       The size in octets of the largest address-family specific datagram
>       found in Table 7-1 of [MTUDISC].  Interface MTU should be set to 0
> ------------------------------------------------------------------------
>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 29 May 2008 16:20:14 -0400

Hi Paul,

On May 29, 2008, at 3:59 PM, Paul Wells wrote:

> Hi Acee,
>
> This scheme looks okay to me. I have a couple of questions/ 
> suggestions, though. You say:
>
> "If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non- 
> IPv6 address families."
>

No - I'd let an implementation set the bit and use the minimum IPv6  
MTU if they wanted to avoid a mismatch with their neighbors. In other  
words, this would handle the case where the routers IPv4 and IPv6  
MTUs were the same but their neighbor's were not.

> match? The text specifies that the router which has differing IPv4/ 
> IPv6 MTUs will send 1280 byte OSPFv3 packets, but it's really the  
> other router(s) on the link that need to do this because they don't  
> know what that router's IPv6 MTU is. I'd suggest changing the third  
> paragraph to something like:
>
> interface's IPv6 MTU and it MUST send OSPFv3 packets no larger than  
> 1280 octets.

I don't think this is necessary - 10.6 of [OSPFv2] says the receiver  
should check that the received MTU is not greater than the receiving  
interface MTU. So, in short, the sender indicates what it will send  
(either explicitly or the minimum) and the receiver verifies that it  
can receive this MTU. Perhaps, I didn't articulate this well but I  
gotta get on another conference call in a couple minutes.

Thanks,
Acee

>> However, I think this is a simpler approach allows an OSPFv3  
>> router to disable IPv6 MTU checking for non-IPv6 address families  
>> even if their IPv6 MTU matches their IPv4 MTU. 2.7.  Database  
>> Description Maximum Transmissoin Unit (MTU)
>> receiving
>>> variation. I say that if the new bit is clear, the 2 MTUs are  
>>> equal  and the specified MTU is simply checked against both MTUs.  
>>> If it is  set, it means the MTUs differ and we need to use the  
>>> IPv6 minimum for  OSPFv3 packet computation. As someone may point  
>>> out, it's actually  more complex - I'll post proposed text  
>>> (hopefully, later today).
>>> Thanks,
>>> Acee
>>>>>>>>>> specify which MTU we should use while exchanging the DD  
>>>>>>>>>> packet
>>>>>>>>>> for the