[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-mech-v2-00.txt
Erik,
Some comments appear in the text below:
Fred Templin
ftemplin@iprg.nokia.com
Erik Nordmark wrote:
For those of you that didn't notice the draft announcement this
is the intended replacement for RFC 2893 with edits since
draft-ietf-ngtrans-mech-v2-nn.txt.
There are no open issues in the document that I am aware of.
If folks have issues please bring them up on the list so we can
try to resolve them before or at the v6ops meeting next week.
The recent changes (copied from the document):
- Clarified that the dynamic path MTU mechanism in section 3.2 is
OPTIONAL but if it is implemented it should follow the rules in
section 3.2.
This method is susceptible to black holes (see RFC 2923).
- Stated that when the dynamic PMTU is not implemented the sender
MUST NOT by default send IPv6 packets larger than 1280 into the
tunnel.
- Stated that implementations MAY have a knob by which the MTU can
be set to larger values on a tunnel by tunnel basis, but that
the default MUST be 1280 and that decapsulators need to be
configured to match the encapsulaltor's MTU.
This method should only be used when care is taken to avoid harmful
levels of
fragmentation in the network (please see my previous note on this
subject). This
needs to be clarified in the draft.
- Restated the "currently underway" language about ToS to loosely
point at [RFC2983] and [RFC3168].
- Stated that IPv4 source MAY also be administratively specified.
(This is especially useful on multi-interface nodes and with
configured tunneling)
- Fixed reference to Assigned Numbers to be to online version
(with proper pointer to "Assigned Numbers is obsolete" RFC)
- Clarified text about ingress filtering e.g. that it applies to
packet delivered to transport protocols on the decapsulating
node as well as packets being forwarded by the decapsulator, and
how the decapsulator's checks help when IPv4 and IPv6 ingress
filtering is in place.
Erik