Hi all,
Delving a bit deeper into this:
> 1) What is the correct level of support for MLD?
> Should MLDv2 be supported as well?
I have gotten comments stating:
MLD should be Conditionally Mandatory based on the use of multicast
"applications" on the node (w
Hi all,
> 2) MIPv6 draft suggestions for Node requirements be accepted?
I've listed below the comments from Mobile IPv6 lastest draft.
I think they breakdown as:
All Nodes MUST be able to process Home Address Optional.
All Nodes MUST be able to send a Binding Error message.
All Nodes MU
Hi all,
> 3) How to support Site Local Addresses.
Brian Haberman said:
A node is only required to support being in 1 site. The issues with
multi-sited nodes is too complex to make a mandatory feature. By
supporting 1 site, the node can treat the site local addresses as
globals.
Bob
John, unfortunately the intermediate version you referenced
didn't yet include changes for the new consensus we reached on
the MIPv6 list. Below you will find the current summarized
situation:
All nodes MUST (no requirements!)
All nodes SHOULD be able to participate in Route Optimization
All node
On Thu, 24 Oct 2002 [EMAIL PROTECTED] wrote:
> Delving a bit deeper into this:
>
> > 1) What is the correct level of support for MLD?
> > Should MLDv2 be supported as well?
>
> I have gotten comments stating:
>
> MLD should be Conditionally Mandatory based on the use of m
Hi Pekka,
> I might a bit hesitant to add a MUST for MLDv2, as MLDv2 is
> new and much more code than MLDv1; rather like MUST for MLDv1
> as above, SHOULD for overall MLDv2.
I tend to agree, but I am not an expert in MLDv2, so I just
want to know what will break if nodes don't impelement it.
Hi Jari,
> John, unfortunately the intermediate version you referenced
> didn't yet include changes for the new consensus we reached on
> the MIPv6 list. Below you will find the current summarized
> situation:
>
> All nodes MUST (no requirements!)
> All nodes SHOULD be able to participate in Rout
[EMAIL PROTECTED] wrote:
Hi Pekka,
I might a bit hesitant to add a MUST for MLDv2, as MLDv2 is
new and much more code than MLDv1; rather like MUST for MLDv1
as above, SHOULD for overall MLDv2.
I tend to agree, but I am not an expert in MLDv2, so I just
want to know what will break if node
On Thu, 24 Oct 2002, Brian Haberman wrote:
> If the point of this document is to tell new implementors what
> they should implement, then my feeiling is that the group
> management protocol should be MLDv2.
I agree.
But there is more to it than just new implementations.
To be fair.. if NodeReqs
Hi!
When unplugging an IPv6 node from an ethernet switchport and
plugging it back into another, the host is not reachable until
the switching table timeout expired (or any ARP timeout occurs).
Therefore, in this respect, IPv6 is not superior to IPv4.
Are there any negative consequences if an IPv
> This is craziness. We (I don't mean just MS) have shipping
> implementations that support site-locals. We have operational
> deployments using site-locals. We have applications that work just fine
> with site-locals.
Could you (or someone else who has this working) publish an ID which
describes
This question came up during one of the ISATAP draft revisions. We
were intending to adopt Marc's proposed reserved address space for
documentation, but couldn't find a proper reference. I favor the
/16 example - it should be large enough to cover unanticipated
future use cases.
Fred
[EMAIL PROTEC
Thomas,
> Thomas Narten wrote:
> The intent of the "documentation prefix" is not for
> describing new protocols. Presumably, documents defining
> new protocols can give examples as they see fit (in IDs),
> and if the ID gets published as an RFC, any addresses
> needed would presumably be allocated
In addition, my intuition is that we don't fully understand the impact and
effect of site-local addresses on, for example, router configuration, DNS,
addressing architecture, etc.
It would help if we had a document describing use cases and open issues
that we could discuss...
- Ralph
At 06:14
On the size of the prefix to allocate for documentation.
In IPv4, the following is reserved per RFC 3330.
>192.0.2.0/24 - This block is assigned as "TEST-NET" for use in
>documentation and example code. It is often used in conjunction with
>domain names example.com or example.net in
Thomas,
> Thomas Narten wrote:
> [192.0.2.0/24]
> This is far less than is needed (strictly speaking) to
> document usages that require shorter prefixes. But I'm
> not aware of this being a problem in practice.
Because there is a solidly established practice of using RFC1918
addresses for documen
Michel Py wrote:
Thomas,
Thomas Narten wrote:
[192.0.2.0/24]
This is far less than is needed (strictly speaking) to
document usages that require shorter prefixes. But I'm
not aware of this being a problem in practice.
Because there is a solidly established practice of using RFC1918
ad
> Alain Durand wrote:
> We need to reserve some equivalent space in
> v6 land. Net 10 allows 16 bits to create a
> hierachy of /24, so we need 16 bits in v6
> lands to create a hierachy of /48. That
> translate into a /32.
Another way to read these numbers:
10. net allows 10 bits to create a hiera
Hi Brian, Rich & Keith,
Maybe the best way forward would be to work on a BCP on Site
Local addresses. This could point out what site-locals are
good for, what they are not good for and some recommendations
on using them.
John
> -Original Message-
> From: ext Brian Haberman [mailto:bkhabs
> Maybe the best way forward would be to work on a BCP on Site
> Local addresses. This could point out what site-locals are
> good for, what they are not good for and some recommendations
> on using them.
I don't think this would solve the problem that I'm concerned about -
which is that the very
Hi Walter,
There's some related discussion going on with
the optimistic DAD draft, which proposes this
idea as part of the optimization for DAD.
Just sending a NA when no-one has data for you
may not have any effect though.
Greg Daley
Walter Zimmer wrote:
Hi!
When unplugging an IPv6 node from
Hi Roy,
Roy Brabson wrote:
This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals. We have operational
deployments using site-locals. We have applications that work just fine
with site-locals.
Could you (or someone else who has this working) publish
> Without standards, or at least
> standards-track IDs, its hard to see how site-locals can be viewed as
> useful beyond a single-site configuration, with anything beyond that being
> experimental and/or proprietary.
more to the point, it's not even clear that we know how to write standards
that
> This is craziness. We (I don't mean just MS) have shipping
> implementations that support site-locals. We have operational
> deployments using site-locals. We have applications that work just fine
> with site-locals.
indeed, some applications work just fine with them. but trying to
make applica
This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals. We have operational
deployments using site-locals. We have applications that work just fine
with site-locals.
Rich
IETF IPng Wo
I think that we should keep site-local addresses in the
addressing architecture, but limit their use to non-globally-
connected IPv6 networks.
Margaret
At 11:02 AM 10/24/02, Keith Moore wrote:
we'd be far better off to deprecate site local addresses, as nobody has
actually given a convincing
> I think that we should keep site-local addresses in the
> addressing architecture, but limit their use to non-globally-
> connected IPv6 networks.
the problem is that even a network that isn't connected directly to
the global internet may have nodes that communicate with other nodes
that are con
Rich,
Just for my edification:
1. Who else has site-local support?
2. Can you describe the operational deployments?
3. What applications?
Thanks,
Brian
Richard Draves wrote:
This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals
we'd be far better off to deprecate site local addresses, as nobody has
actually given a convincing case for their use.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP a
>
> I think that we should keep site-local addresses in the
> addressing architecture, but limit their use to non-globally-
> connected IPv6 networks.
>
=> Agreed. Another useful use is that long lived
connections within a site can survive renumbering.
Hesham
---
30 matches
Mail list logo
