Christian Huitema wrote:
Frankly, I don't believe that we should worry about net 10 in the site
local deprecation draft. The site local deprecation document is
specifically about the prefix 0xFEC0::/10. In any case, such addresses
are explicitly banned in the IPv6 addressing architecture.
Hi,
I just about used up all my aspirin and tranquilizers trying to read
this message constructively and trying to write a constructive reply
to this message but failed.
I don't think this document is constructive as a requirements
document, and I'll strongly oppose it being adopted as WG
Hi Eric,
I have been speaking to different
companies here in Israel, and the basic answer is that if I
can not have site locals and NAT then I will not move to IPv6.
If these people are happy with IPv4 NAT, why would they want
to move to IPv6? They couldn't need more address space (net
Margaret.Wasserman wrote
I have been speaking to different
companies here in Israel, and the basic answer is that if I
can not have site locals and NAT then I will not move to IPv6.
If these people are happy with IPv4 NAT, why would they want
to move to IPv6? They couldn't need more
On Wed, Nov 19, 2003 at 03:12:16PM +0200, EricLKlein wrote:
This is not the first time that I have heard that someone was willing to
skip IPv6 because of the percieved pain and security threat that standards
compliance would entail. But then again these are all people that take
security and
[EMAIL PROTECTED] writes:
Nodes MUST always be able to receive fragment headers. However, if it
does not implement path MTU discovery it may not need to send
fragment headers. However, nodes that do not implement transmission
of fragment headers need to impose a
Thomas,
how about:
Nodes MUST always be able to send and receive fragment
headers. Note that even in the case where a sender does not
implement or use Path MTU discovery [RFC 1981], the sender
must still be prepared to send fragment headers, even for
packets
Here are some comments from Margaret.
John
-Original Message-
From: Wasserman Margaret (NRC/Boston)
Hi John,
I have reviewed the IPv6 Node Requirements draft. In general,
I think tha the document looks good, but I do have several comments
(attached). I believe that an update
NITS, my comments preceded by JAL:
As it is not always possible for an implementer to know the exact
usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
that they should adhere to John Postel's Robustness Principle:
Be conservative in what you do, be liberal in
Margaret asked 2 points:
11. Security Considerations
In the IPsec section, you mention that other security issues
will be covered in the Security Considerations section, but
I don't see any issues here...
Why aren't privacy addresses covered in this document?
Should this be covered in
Thomas Narten wrote:
Nodes MUST always be able to receive fragment headers. However, if it
does not implement path MTU discovery it may not need to send
fragment headers. However, nodes that do not implement transmission
of fragment headers need to impose a limitation to the payload size
[EMAIL PROTECTED] wrote:
An IPv6 node must include support for one or more IPv6 link-layer
specifications. Which link-layer specifications are included
will depend upon what link-layers are supported by the hardware
available on the system. It is possible for a conformant IPv6
node to support
Jari,
4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
If an application is going to join any-source multicast group
addresses, it SHOULD implement MLDv1. When MLD is used, the rules in
Source Address Selection for the Multicast Listener Discovery (MLD)
Protocol
I'm OK with the proposed text, except Pekka Savola asked me if it should
be changed to:
Nodes MUST always be able to send, receive and process fragment
^^^
headers. Note that even in the case where a sender does not
[EMAIL PROTECTED] wrote:
Perhaps the only question that I have left is... whether
IPv6 nodes should support MLDv2 instead of MLDv1. The
node requirements document and the MLDv2 draft intro
gives the impression that the only difference is
source-specific filtering. Then the current node
reqs rules
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Perhaps the only question that I have left is... whether
IPv6 nodes should support MLDv2 instead of MLDv1. The
node requirements document and the MLDv2 draft intro
gives the impression that the only difference is
source-specific filtering. Then the
Brian Haberman wrote:
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Perhaps the only question that I have left is... whether
IPv6 nodes should support MLDv2 instead of MLDv1. The
node requirements document and the MLDv2 draft intro
gives the impression that the only difference is
source-specific
It's also possible for DCCP to get a better initial estimate of the PMTU,
and apparently there are other problems with the current DCCP PMTUD
mechanism (using ICMP can't fragment messages).
Yes -- The current draft tries to make clear (but fails to) that a new,
PLPMTUD-style MTU discovery
Eddie,
Yes, I agree with the idea of initially plumbing the path MTU
when a connection starts up. If the application has lots of data to
send, it might initially try to plumb out to the largest possible
MTU; if only a little, it might be less aggressive during startup.
It might also be desireable
Jean-Jacques Pansiot wrote:
Brian Haberman wrote:
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Perhaps the only question that I have left is... whether
IPv6 nodes should support MLDv2 instead of MLDv1. The
node requirements document and the MLDv2 draft intro
gives the impression that the
Brian Haberman wrote:
So, I think I answered this already in an earlier message, but let
me clarify something here. The IP stack layer really does not know
what kinds of multicast applications are going to be run on it.
A user could arbitrarily install an SSM application just as easily
as an ASM
21 matches
Mail list logo
