On Sat, 25 Oct 2003, Bound, Jim wrote:
> I believe there is another option. Develop new spec that does number 3
> below to add to 2461 and leave 2461 alone. This would be a spec
> defining a new option for 2461.
Or, even define the new interpretation for MTU over NA messages in a
separate spec
Hello Jim
> I have read this spec and don't see bugs at this point. Is this
> document to feed work on MIB definitions for SNMP and network
> management? Or just to describe as information the various states in
> the draft?
The original intent is to be a Informational RFC as a result
of our imp
I believe there is another option. Develop new spec that does number 3
below to add to 2461 and leave 2461 alone. This would be a spec
defining a new option for 2461.
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Fred Templin
> Sent: Frida
I see (at least) three ways for the neighbor-to-neighbor MTU negotiation;
two were presented in my drafts and the third is presented by Iljitsch here.
The methods are:
1) Change RFC 2461 to allow NA messages to include MTU options:
Advantages:
- Unambiguous mechanism for NA's to inform of
Erik Nordmark wrote:
Such a capability would enhance a layer 3 neighbor MTU management
capability, but it isn't required. Operators can simply have routers
annouce an upper limit on the MTU that may be used on a subnet. This
doesn't impede the best case scenario where all the switches support
Pekka Savola wrote:
On Thu, 23 Oct 2003, Iljitsch van Beijnum wrote:
[...]
See http://sd.wareonearth.com/~phil/net/jumbo/ for some links
surrounding this issue.
Yes, and...?
Even if you don't want a separate physical infrastructure, defining a VLAN
is trivial.
Where the L2 supports tha
Erik Nordmark wrote:
Currently, routers can advertise an MTU for a link. That's nice. But
what we really need is a way for hosts to find out the MTU each
individual neighbor can handle. 100 Mbps and slower ethernet interfaces
can typically handle only the standard 1500 byte ethernet MTU, whil
Pekka Savola wrote:
On Thu, 23 Oct 2003, Jun-ichiro itojun Hagino wrote:
[...]
the assumption made in RFC2461 is that the link MTU is constant
over the link, i guess. i don't think it is necessary to make
MTU negotiable between peers, it would complicate too many things.
FWIW, I agre
Itojun,
I disagree with your statement. Two examples where the per-neighbor MTU
negotiation would be very useful:
1) Peer-to-peer wireless (e.g. IEEE 802.11):
On certain wireless media, receiver A can sense QoS metrics (e.g. SNR)
for the packets it receives from senders B and C. If the SNR f
Comments on this draft. I am unclear but it may be this work needs to
be done in the mipshop WG within the Internet Area as I believe all that
is required to resolve the problem statement in this draft is policy to
use the current ND 2461 mechanisms and the extended ND mechanisms in
MIPv6. As the
I had this question yesterday and I couldn't find an answer in RFC2460:
Is it valid for a host to send a packet with Hop Count set to zero?
- Alain.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Reque
I have read this spec and don't see bugs at this point. Is this
document to feed work on MIB definitions for SNMP and network
management? Or just to describe as information the various states in
the draft?
/jim
IETF IPv6 worki
Erik,
The goal at this point is to recycle at DS. I have a query
into the ADs as to whether or not we should consider moving it
to Full Standard.
Given that target, the primary goal is to clarify issues in
the spec. I feel that including some additional definitions, such
as the MIPv6 R
Soliman Hesham wrote:
>
> when a router includes a Prefix Information Option (section
> 4.6.2 of RFC 2461) in the Router Advertisement, and if the
> router has an address configured from that prefix, I suggest
> including the router's address in the 'Prefix' field. not
> just the prefix. th
Some notes on the draft as well as some of the comments on the list:
1. I think this draft is appropriately being prepared as Proposed
Standard. Trying to side-line local addressing to Experimental is not in
keeping with the declared consensus on work towards a "replacement for
site-locals" (
Hello,
A new version of the 'hain/templin' draft is now available (see below).
This version obsoletes the previous document named:
"Goals for an Addressing Scheme to Support Local Communications within
Sites"
draft-hain-templin-ipv6-limitedrange-02.txt
Fred
[EMAIL PROTECTED]
A New Internet-Dr
[EMAIL PROTECTED] wrote:
> Title : Textual Representation of IPv4 and IPv6 Addresses
> Author(s) : A. Main
> Filename: draft-main-ipaddr-text-rep-01.txt
> Pages : 12
> Date: 2003-10-23
...
>A URL for this Internet-Draft is:
Hi Dave,
thanks for the comments!
John
> -Original Message-
> From: ext Dave Thaler [mailto:[EMAIL PROTECTED]
> Sent: 23 October, 2003 00:06
> To: Loughney John (NRC/Helsinki)
> Cc: [EMAIL PROTECTED]
> Subject: RE: Review of draft-ietf-ipv6-node-requirements-05.txt
>
>
> The following
Hi Chirayu,
> > All nodes need to be able to terminate packets. All nodes may be able
> > to route packets.
>
> The capability of being a final destination includes support for sending
> NS, RS messages etc (basically being a host). If all nodes MUST support
> the capability of being a final d
On Fri, 24 Oct 2003, jspark wrote:
> > But it is mandated by the specs. So
> > these addresses are
> > *not* truly, completely, totally, unique.
>
> In our spec.
> The uniqueness of LL unicast address is verified by DAD procedure.
> And then, EUI-64 IID (or other) is extracted from LL Unicast add
Hi
I don't get:
1°) The need for such link-local adresses. Maybe it should be
described in the document (saying you will not need any allocation
server or equivalent is not enough I think). What type of applications
you think will need these link-local adresses?
2°) Why to use the flag bi
Vijay,
thanks for raising this. A question below.
> here is another issue.
>
> when a router includes a Prefix Information Option (section
> 4.6.2 of RFC 2461) in the Router Advertisement, and if the
> router has an address configured from that prefix, I suggest
> including the router's a
-Original Message-
From: jspark [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 7:51 PM
To: 'Pekka Savola'
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Hi Pekka.
On Fri, 24 Oct 2003, Pekka Savola wrote:
> First, there is typically just one link-local address.
> Either it
[moved this to ipv6 list]
Nick,
Thanks, I'll add this to the list.
Hesham
> -Original Message-
> From: Nick 'Sharkey' Moore [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 24, 2003 3:28 AM
> To: [EMAIL PROTECTED]
> Cc: Soliman Hesham
> Subject: Re: RFC 2461- issue list
>
>
24 matches
Mail list logo
