none of the above document specify what IPv6 MTU to use for these
interfaces. (RFC3056 has a pointer to RFC2893, but RFC2893 has nothing
about IPv6 MTU)
I see these words in RFC 2893 which seem to be relevant to this issue:
The IPv6 layer in the encapsulating node can
since there's no standard, some implementation can be picky and
assume MRU == MTU. maybe RFC2893 should talk more about MRU and MTU.
How about:
A node implementing RFC 2893 MUST be able to reassemble IPv4 packets
of a size up to and including 65353 octets and MUST
Hi,
On Mon, 5 Aug 2002, Margaret Wasserman wrote
in Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt:
In the Yokohama meeting, Steve Deering lead a
discussion on the uniqueness of IIDs, and there
was a pretty big majority of people in the room
who thought that we shouldn't even
none of the above document specify what IPv6 MTU to use for these
interfaces. (RFC3056 has a pointer to RFC2893, but RFC2893 has nothing
about IPv6 MTU)
I see these words in RFC 2893 which seem to be relevant to this issue:
The IPv6 layer in the encapsulating node can
Hi Margaret,
Thank you for your clarification. I now get the point.
This change would modify the scope of that uniqueness
to be a subnet prefix, not the whole link. So,
within a set of interfaces using a particular
subnet prefix, the IID would identify a particular
interface.
(..)
% But I take it from your question that you'd like to see a fixed number for
% the MTU. Is this really necessary?
%
% yes, it definitely needs to be a fixed number. in other words, IPv6
% link MTU should not be computed based on IPv4 PMTU (which is dynamic).
% PMTUD assumes
for cross-talk to occur, is there a presumption of fate-sharing
on links? e.g. do you presume that a single link will always
support both v4 and v6?
no, i do not assume that. since this is a document about tunnelling,
IPv4 path could be arbitrary (some of
Hi Robert,
Though, it is not entirely clear to me why
the /subnet IID uniqueness rather than the /link
uniqueness makes the case of privacy addresses easier.
To ensure IID uniqueness on a link, a node that implements
privacy addresses would need to generate a link-local
address for each
yes, it definitely needs to be a fixed number. in other words, IPv6
link MTU should not be computed based on IPv4 PMTU (which is dynamic).
PMTUD assumes that link MTUs are stable enough.
I know of no such assumption.
In fact PMTUD is designed deal with routing using
yes, it definitely needs to be a fixed number. in other words, IPv6
link MTU should not be computed based on IPv4 PMTU (which is dynamic).
PMTUD assumes that link MTUs are stable enough.
I know of no such assumption.
In fact PMTUD is designed deal with routing using different
i haven't seen links that changes MTU (*1) dynamically based on
dynamic changes from outside (*2). in this case (*1) is IPv6 MTU
on top of tunnel and (*2) is IPv4 routing changes.
maybe my experience is limited, but anyway, i have never seen one.
I having a hard time
I having a hard time parsing this regular expression.
I'm also having a hard time writing :-)
I meant to say
I'm having a hard time parsing this regular expression :-)
Erik
IETF IPng Working Group Mailing List
- Original Message -
From: Erik Nordmark [EMAIL PROTECTED]
I meant to say
I'm having a hard time parsing this regular expression :-)
http://www.rebol.com/
C@t will be back...
Jim Fleming
2002:[IPv4]:000X:03DB
http://www.iana.org/assignments/ipv4-address-space
From: Margaret Wasserman [EMAIL PROTECTED]
To ensure IID uniqueness on a link, a node that implements
privacy addresses would need to generate a link-local
address for each randomly generated IID (in addition to the
global address generated for privacy), perform DAD on
that address, and
At the IPv6 working group sessions at the Yokohama IETF two changes to the
IP Version 6 Addressing Architecture draft
draft-ietf-ipngwg-addr-arch-v3-08.txt
were discussed. These changes were proposed based on feedback received
from our area director and email discussion on the mailing
Has the ICANN Board and staff approved this ?
Jim Fleming
2002:[IPv4]:000X:03DB
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
- Original Message -
From: Bob Hinden [EMAIL PROTECTED]
To: IPv6 List [EMAIL PROTECTED]
At a minimum, implementations should be able to convert the=20
ICMP errors happening from within the IPv4 tunnel back to
ICMPV6 error and send it back to the original sender (IPv6 sender
in case of IPv6 over IPv4 tunnels). Otherwise path mtu
discovery will never work assuming you set the DF bit
kre,
What you are calling for (quoted below) is lots of changes. With that
many deletions, one might say that it could be wiser to re-write
[addrarch] entirely.
Note that I don't oppose the idea and I acknowledge that you do have
very good points, but WRT what Margaret mentioned earlier about
well Michael, the wg has a choice:
proceed w/ the arch doc as defined, disenfranchising operators
and the spirit of the original design goals.
or.
make changes to the arch doc based on operational experience.
one choice will keep the IETF work relevent
19 matches
Mail list logo
