In your previous mail you wrote:
> There is an issue with using a MAC-based link local address on an interface
> that does not have that MAC address, which is that any other interface
> using that MAC that turns up is going to fail DAD. Normally this will be
> another interface
Le 2013-04-08 01:13, Andrew McGregor a écrit :
There is an issue with using a MAC-based link local address on an
interface that does not have that MAC address, which is that any other
interface using that MAC that turns up is going to fail DAD. Normally
this will be another interface on the
There is an issue with using a MAC-based link local address on an interface
that does not have that MAC address, which is that any other interface
using that MAC that turns up is going to fail DAD. Normally this will be
another interface on the same device, but even then it can be an issue
In your previous mail you wrote:
> The only way to address that condition is to make MAC change and address
> renewal an atomic operation.
=> in fact it is not required to be really atomic, only to seem to be
atomic for an external observer (i.e., it is enough to shutdown the NIC
during the op
y wrong.
=> I deeply disagree: you assume a binding between layers 2 and 3, in
particular between addresses, which does *not* exist. There is no issue
to use any legal link-local address on a particular Ethernet device,
and this is fully independent of the MAC address.
Regards
f
>
> From: Christian Huitema
>To: Brian E Carpenter ; Andrew McGregor
>
>Cc: "ipv6@ietf.org"
>Sent: Saturday, 6 April 2013 2:35 AM
>Subject: RE: link local address handling while changing hw address of interface
>
>&g
> At layer 2, yes, but you haven't done anything at layer 3, and NUD/ND will
> pick up the new layer3:layer2 relationship.
There is also a privacy angle to this. Suppose that a visitor to a café changes
their MAC address in order to avoid tracking. Keeping the same IP addresses
would somewhat d
On 05/04/2013 14:53, Andrew McGregor wrote:
> B) is usually correct, although this depends on the semantics of the lower
> layer in question. If it is Ethernet, by changing the MAC address, you have
> made a new interface and so the old address end point has gone away.
At layer 2, yes, but you ha
B) is usually correct, although this depends on the semantics of the lower
layer in question. If it is Ethernet, by changing the MAC address, you have
made a new interface and so the old address end point has gone away. It is
usually best to drop the link and restart layer 2 at that point, as any
s
In your previous mail you wrote:
> On 04/04/2013 18:51, Hannes Frederic Sowa wrote:
> > Hello!
> >
> > What is the proposed action if the hardware address of an interface is
> > changed regarding link-local addresses while the interface is up? I see
> > a few possibilities here but have no
On 04/04/2013 18:51, Hannes Frederic Sowa wrote:
> Hello!
>
> What is the proposed action if the hardware address of an interface is
> changed regarding link-local addresses while the interface is up? I see
> a few possibilities here but have not yet found an answer in the rfcs:
>
> a) generate a
Hello!
What is the proposed action if the hardware address of an interface is
changed regarding link-local addresses while the interface is up? I see
a few possibilities here but have not yet found an answer in the rfcs:
a) generate a new link-local interface address in addition to the old one
b)
On 5/7/12 12:40 CDT, Dan Luedtke wrote:
Hello,
On Mon, May 7, 2012 at 7:32 PM, Dave Thaler wrote:
MUST NOT would seem to match the intent of the original
RFCs which say:
" Routers must not forward any packets with link-local source or
destination addresses to other links."
Got it now,
Hello,
On Mon, May 7, 2012 at 7:32 PM, Dave Thaler wrote:
> MUST NOT would seem to match the intent of the original
> RFCs which say:
> " Routers must not forward any packets with link-local source or
> destination addresses to other links."
Got it now, thanks :) Yes, weakening the requiremen
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Dan Luedtke
> Sent: Monday, May 07, 2012 10:21 AM
> To: David Conrad
> Cc: Christian Huitema; 6man
> Subject: Re: There are claims of ambiguity over what is a link-
Hi,
On Mon, May 7, 2012 at 7:07 PM, David Conrad wrote:
>> * FE80::/64 is used for configuring link local addresses;
>> * FE80::/10 is reserved by the IETF.
>> * By default, implementations SHOULD discard packets received from addresses
>> in FE80::/10 outside of FE80::/64
> I personally believe
Sent from my iPhone
On May 7, 2012, at 9:57 AM, "Christian Huitema" wrote:
>>> Link-Local Unicast Addresses 1110 10 1/1024
>>> Site-Local Unicast Addresses 1110 11 1/1024
>> ...
>> So they define the /10 as the link local *prefix*, within which any
>> *addresse
Hi,
On May 7, 2012, at 9:54 AM, Christian Huitema wrote:
> Given that, I would suggest to be very specific:
+1
> * FE80::/64 is used for configuring link local addresses;
> * FE80::/10 is reserved by the IETF.
> * By default, implementations SHOULD discard packets received from addresses
> in
>> Link-Local Unicast Addresses 1110 10 1/1024
>> Site-Local Unicast Addresses 1110 11 1/1024
>...
> So they define the /10 as the link local *prefix*, within which any
> *addresses* have to fall into the /64.
> The rest of the /10 is unused but is still defined as
all into the /64.
The rest of the /10 is unused but is still defined as link-local
scope.
-Dave
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Alexandru Petrescu
> Sent: Monday, May 07, 2012 12:51 AM
> To: ipv6@ietf.org
>
That ambiguity around the prefix length /10 vs /64 of a link-local
address should be clarified.
If clarified, among other advantages, it would allow to write C code
which, when typing "ifconfig eth0 add fe80::1" it would know to fill in
the prefix length by itself, and not wonder a
On 2012-05-07 00:59, Mark Andrews wrote:
> See the nanog thread starting here:
> http://mailman.nanog.org/pipermail/nanog/2012-May/048079.html
>
I'm sure the intention was to reserve the entire /10 prefix
but it's correct that the RFC is not clear about this.
Seems like an erratum is
See the nanog thread starting here:
http://mailman.nanog.org/pipermail/nanog/2012-May/048079.html
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
--- On Thu, 5/27/10, Brian Zill wrote:
> From: Brian Zill
> Subject: RE: which interface to choose to send to destination link-local
> address - any RFC?
> To: "Parav Pandit"
> Cc: "ipv6@ietf.org"
> Date: Thursday, May 27, 2010, 10:24 PM
> Hi Para
On May 27, 2010, at 09:54, Brian Zill wrote:
>
> [...]
> Typically, any reasonable protocol that uses link-local addresses will learn
> any peer's addresses by receiving packets from that peer on that particular
> link. The protocol will then keep both the link-local addres
use addresses
> that are valid in that scope (i.e. global addresses).
>
> Typically, any reasonable protocol that uses link-local addresses will learn
> any peer's addresses by receiving packets from that peer on that particular
> link. The protocol will then keep both the li
ocol that uses link-local addresses will learn
any peer's addresses by receiving packets from that peer on that particular
link. The protocol will then keep both the link-local address *and* the
scope-id for that address for later use in contacting that peer.
You should never need to resort
esh Krishnan
> Subject: Re: which interface to choose to send to destination link-local
> address - any RFC?
> To: "Parav Pandit"
> Cc: "ipv6@ietf.org"
> Date: Thursday, May 27, 2010, 8:04 PM
> On 10-05-27 09:28 AM, Brian Haberman
> wrote:
> > You will ne
On 10-05-27 09:28 AM, Brian Haberman wrote:
You will need the scope_id in order to use ping6. In order to send any
packet to a link-local address, you will need the scope_id first.
+1. So my question to you is, how did you get the LL address in the
first place? That should give you clues as
s done only once.
You will need the scope_id in order to use ping6. In order to send any
packet to a link-local address, you will need the scope_id first.
>
> My understanding is, RFC 4443 of ICMPv6 mandates ECHO request and
> response processing. so I believe it should be o.k
response processing.
so I believe it should be o.k to rely on ping6 to get the right interface_id.
Regards,
Parav Pandit
--- On Thu, 5/27/10, Mikael Abrahamsson wrote:
> From: Mikael Abrahamsson
> Subject: Re: which interface to choose to send to destination link-local
> address - any
On Thu, 27 May 2010, Parav Pandit wrote:
I don't know on which vlan the destination link-local address is.
Well, you pretty much know that to send packets to it. A link-local
address is not just an address, you need to provide what interface you're
referring to. It's of l
Opening the thread again.
In my server I have #19 vlans configured on 10Gb Ethernet card.
I don't know on which vlan the destination link-local address is.
1. As a user am I supposed to do ping6 on all of them one by one?
2. How does the TCP will work? Open #19 connections to the destin
destination "all-node multicast address"? If it is yes, As per
> RFC3810, MLD report should not use for joining into all node multicast
> address.?
>
> >> Why the node is sending unsolicited NA message ( with source as
> "link-local address" & destin
ocket()
> call is unaffected since it doesn't take any address parameter. In the
> connect() call, for the struct sockaddr parameter, the sin6_addr member
> will contain the server's link-local address and the sin6_scope_id
> member will contain the scope id of the client&#
ed node multicast address.
>> Why the node is sending unsolicited NA message ( with source as "link-local
>> address" & destination as "all-node multicast address").
>> I am expecting only one unsolicited NA message( with source as "ipv6 global
>&g
source as "link-local address" & destination as "all-node multicast
address").I am expecting only one unsolicited NA message( with source as
"ipv6 global address" & destination as "all-node multicast address"). I am
not at all changing the link-local addr
tried this scenario , I have seen two NA messages.
1) source as ipv6 address and destination as ipv6 all node address.
2) source as link-local address and destination as ipv6 all node address.
My question is, whenever there is a change in ipv6 address on a node,
both these 2 NA messages will
>> My question is, whenever there is a change in ipv6 address on a node, both
>> these 2 NA messages will propogate through the network?
>> or is it really required to share about the link-local address as we are not
>> at all changing the ipv6 link-local address.?
If li
address.
2) source as link-local address and destination as ipv6 all node address.
My question is, whenever there is a change in ipv6 address on a node, both
these 2 NA messages will propogate through the network?
or is it really required to share about the link-local address as we are not
at all
Hi Alex,
On 10-04-16 12:00 PM, Alexandru Petrescu wrote:
Le 16/04/2010 17:11, Suresh Krishnan a écrit :
1) MLD join for the solicited node multicast address from the
unspecified address (to test for the uniqueness of the tentative
link-local address).
2) MLD join for the solicited node
Please fine inline response.
Parav
--- On Fri, 4/16/10, Suresh Krishnan wrote:
> From: Suresh Krishnan
> Subject: Re: deriving MAC address from destination Link local address without
> Neighbor discovery
> To: "Parav Pandit"
> Cc: "ipv6@ietf.org"
>
Local address to
the ‘All node multicast address’. Any specific reason for this? Is
this a correct behaviour ?or is there any requirement for joining link
local address on the all node multicast node while creating an ipv6
address on the interface? why it is required? if it is required, then
this
cal address to the ‘All
node multicast address’. Any specific reason for this? Is this a
correct behaviour ?or is there any requirement for joining link local
address on the all node multicast node while creating an ipv6 address on
the interface? why it is required? if it is required, then this mess
while configuring an
ipv6 address. I could see IPv6 node (Ipv6 address) joining ‘All node
multicast address’ and ‘Solicited multicast address’. Apart from that I am
seeing an extra join request from the Link Local address to the ‘All node
multicast address’. Any specific reason for this? Is this a
Hi Parav,
Please see comments inline.
On 10-04-15 01:55 AM, Parav Pandit wrote:
Hi,
As per RFC 2464, Link local address for Ethernet based interfaces are based on
the EUI-64 (derived from the MAC address).
I have #3 questions based on this.
In this case,
when one Ethernet based host(from
both the methods are correct for ETHERNET for Link-local and autoconf
> addresses?
>
> RFC 4291 asks to refer the Link layer specific RFC for the 64-bit Interface
> Id of the link-local address - which is 2464 (for Ethernet).
>
> So thats the confusion I have.
>
> Or
> t
Le 15/04/2010 15:17, Cameron Byrne a écrit :
On Thu, Apr 15, 2010 at 2:31 AM, Alexandru Petrescu
wrote:
Le 15/04/2010 07:55, Parav Pandit a écrit :
Hi,
As per RFC 2464, Link local address for Ethernet based interfaces
are based on the EUI-64 (derived from the MAC address).
Right, that is
On Thu, Apr 15, 2010 at 2:31 AM, Alexandru Petrescu
wrote:
> Le 15/04/2010 07:55, Parav Pandit a écrit :
>>
>> Hi,
>>
>> As per RFC 2464, Link local address for Ethernet based interfaces
>> are based on the EUI-64 (derived from the MAC address).
>
> Right,
Inline.
Parav
--- On Thu, 4/15/10, Alexandru Petrescu wrote:
> From: Alexandru Petrescu
> Subject: Re: deriving MAC address from destination Link local address without
> Neighbor discovery
> To: "Parav Pandit"
> Cc: "Ipv"
> Date: Thursday, April 1
Le 15/04/2010 07:55, Parav Pandit a écrit :
Hi,
As per RFC 2464, Link local address for Ethernet based interfaces
are based on the EUI-64 (derived from the MAC address).
Right, that is probably a very widespread way of how the link local
addresses are derived from a MAC address.
There are
Or both the methods are correct for ETHERNET for Link-local and autoconf
addresses?
RFC 4291 asks to refer the Link layer specific RFC for the 64-bit Interface Id
of the link-local address - which is 2464 (for Ethernet).
So thats the confusion I have.
Or
the RFC 3972 doesn't apply to the
=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD)
On Apr 14, 2010, at 10:55 PM, Parav Pandit wrote:
> Hi,
>
> As per RFC 2464, Link local address for Ethernet based interfaces are based
> on the EUI-64 (derived from the MAC address).
>
> I have #3 questions based on
Hi,
As per RFC 2464, Link local address for Ethernet based interfaces are based on
the EUI-64 (derived from the MAC address).
I have #3 questions based on this.
In this case,
when one Ethernet based host(from its link-local source) tries to ping the
other Ethernet based host, it knows the
ct the outgoing interface to choose (when multiple
> interfaces) are available? Typically when the destination is the link-local
> address which may be on-link on both the interfaces (before the neighbor
> discovery) is done?
>
> Should IPv6 stack do Neighbor discovery on all mult
take any address parameter. In the
connect() call, for the struct sockaddr parameter, the sin6_addr member
will contain the server's link-local address and the sin6_scope_id
member will contain the scope id of the client's interface on which the
server can be reached.
Based on
,
Parav Pandit
--- On Wed, 4/14/10, Mohacsi Janos wrote:
From: Mohacsi Janos
Subject: Re: which interface to choose to send to destination link-local
address - any RFC?
To: "Parav Pandit"
Cc: ipv6@ietf.org
Date: Wednesday, April 14, 2010, 3:01 PM
On Wed, 14 Apr 2010, Parav Pa
On Wed, 14 Apr 2010, Parav Pandit wrote:
Hi,
In IPv6 stack implementation,
How IPv6 stack should select the outgoing interface to choose (when multiple
interfaces) are available?
Typically when the destination is the link-local address which may be on-link
on both the interfaces (before
On Wed, 14 Apr 2010 02:00:36 -0700 (PDT), Parav Pandit
wrote:
> How IPv6 stack should select the outgoing interface to choose (when
> multiple interfaces) are available? Typically when the destination is the
> link-local address which may be on-link on both the interfaces (before
the
&
Hi,
In IPv6 stack implementation,
How IPv6 stack should select the outgoing interface to choose (when multiple
interfaces) are available? Typically when the destination is the link-local
address which may be on-link on both the interfaces (before the neighbor
discovery) is done?
Should IPv6
mark ; Prabhu Hariharan <
> prab...@gmail.com>
> Cc: ipv6@ietf.org
> Sent: Wednesday, June 10, 2009 9:14:53 PM
> Subject: RE: Is Link-Local address mandatory for a host device?
>
> Erik Nordmark wrote:
>
> >I suspect that you also can't use DHCPv6 for non-addr
escape from the link-locals.
Regards,
Behcet
- Original Message
From: Hemant Singh (shemant)
To: Erik Nordmark ; Prabhu Hariharan
Cc: ipv6@ietf.org
Sent: Wednesday, June 10, 2009 9:14:53 PM
Subject: RE: Is Link-Local address mandatory for a host device?
Erik Nordmark wrote:
>I susp
Erik Nordmark wrote:
>I suspect that you also can't use DHCPv6 for non-addresses (finding the
>DNS servers etc) since DHCPv6 might assume that some communication uses
>the link-local address. But I haven't checked in the RFC.
Snipped from RFC 3315, section 1.1 is:
[
In your previous mail you wrote:
For a end-device (a host), if the interface connecting to IPv6 network is
configured with IPv6 global address, then automatic configuration of
link-local address is mandatory for that interface? Consider the host is
being statically configured with
etf.org] On Behalf Of
Erik
>Nordmark
>Sent: Wednesday, June 10, 2009 1:39 PM
>To: Prabhu Hariharan
>Cc: ipv6@ietf.org
>Subject: Re: Is Link-Local address mandatory for a host device?
>
>Prabhu Hariharan wrote:
>> Hi,
>>
>> For a end-device (a host), if the int
Prabhu Hariharan wrote:
Hi,
For a end-device (a host), if the interface connecting to IPv6 network
is configured with IPv6 global address, then automatic configuration of
link-local address is mandatory for that interface? Consider the host
is being statically configured with IPv6 default
Hi,
For a end-device (a host), if the interface connecting to IPv6 network is
configured with IPv6 global address, then automatic configuration of
link-local address is mandatory for that interface? Consider the host is
being statically configured with IPv6 default gateway address.
Without the
On Thu, Nov 02, 2006 at 03:54:08PM +0530, kernel learner wrote:
> In IPv6 whenever a NS packet is received,
> and if the target address is link local, then second 16 bits from lsb side
> are fileed with interface index. and while sending NA as reply those bits in
> target address are made zero. Why
Hi all,
In IPv6 whenever a NS packet is received,
and if the target address is link local, then second 16 bits from lsb
side are fileed with interface index. and while sending NA as reply
those bits in target address are made zero. Why is it done?
Acc. to rfc, those 16bits are part of 64 bit int
Hi,
Since Link Local Address is basic for interface's ipv6 capability, such as
usage by ND,
I also agree not to forward packets at this case.
Thanks
Leon
- Original Message -
From: "JINMEI Tatuya / 神明達哉" <[EMAIL PROTECTED]>
To: "Hanamantapppa Yuvraj-A213
>>>>> On Fri, 13 Oct 2006 15:02:19 +0800,
>>>>> "Hanamantapppa Yuvraj-A21366" <[EMAIL PROTECTED]> said:
> Suppose for a Router Fast Ethernet interface has a following
> configuration
> Link Local Address which is Tentative, and the Prim
Hi
All,
Suppose for a Router Fast Ethernet interface has a following
configuration
Link
Local Address which is Tentative, and the Primary IPv6 address
is Up. With this should I be able to forward the Ipv6
traffic?
Appreciate your response
Thanks
Yuvraj
AIL PROTECTED]Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ipv6@ietf.org; [EMAIL PROTECTED]Envoyé le : Jeudi, 14 Septembre 2006, 6h11mn 12sObjet : Re: MTU on a Link Local Address.
[EMAIL PROTECTED] wrote:> Hi all, as we all know Link Local addresses and communicating through them ar
possible to set the MTU also for the Link Local IPv6 address.
The question I have for this forum is what is the MTU value that should be set
for this Link Local address?
Possibilities:
1. 1280 --- the reason is that this value would guarantee a Neighbor
Discovery operation since all devices must
on a Link Local Address.
Don't forget though that tunnels are also links with link-local
addresses and there may be arbitrary physical link technologies
(with heterogeneous MTUs) on the paths between tunnel endpoints.
All links are required to support a minimum MTU of 1280 bytes for
IPv6, and
> I wonder if the grouping together devices with the same MTU/MRU
> capabilities into different on-link prefixes, and then having a
> per-prefix MTU would overcome some of the per-neighbour MTU issues
> identified at that time.
Well, fe80::/10 is an on-link prefix and in some use-cases
there might
ssage-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 8:02 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ipv6@ietf.org;
[EMAIL PROTECTED]
Subject: Re: MTU on a Link Local Address.
Hi Sasson,
It should be 2. the MTU of th
> To: sasson, shuki
> Cc: harris, arthur; ting, dennis; viswanadha, kamakshi; ipv6@ietf.org;
> nathanson, daphna
> Subject: Re: MTU on a Link Local Address.
>
> On Thu, 14 Sep 2006 10:02:02 -0400
> [EMAIL PROTECTED] wrote:
>
> > Hi all, as we all know Link Local addres
address.
The question I have for this forum is what is the MTU value that should be set
for this Link Local address?
Possibilities:
1. 1280 --- the reason is that this value would guarantee a Neighbor
Discovery operation since all devices must support at least this MTU.
2. The MTU of NIC
Thanks!
Shuki
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 11:02 AM
To: sasson, shuki
Cc: ipv6@ietf.org; harris, arthur; [EMAIL PROTECTED]; viswanadha, kamakshi;
nathanson, daphna
Subject: Re: MTU on a Link Local Address.
Hi
-Original Message-
From: Mark Smith
[mailto:[EMAIL PROTECTED]
Sent: Thursday, September 14, 2006 10:27 AM
To: sasson, shuki
Cc: harris, arthur; ting, dennis; viswanadha, kamakshi; ipv6@ietf.org;
nathanson, daphna
Subject: Re: MTU on a Link Local Address.
On Thu, 14 Sep 2006 10:02:02 -0400
[EMAIL
MTU for and IPv6 address. So it is very much
> possible to set the MTU also for the Link Local IPv6 address.
> The question I have for this forum is what is the MTU value that should be
> set for this Link Local address?
>
> Possibilities:
>
> 1.1280 --- the reason is
Link Local IPv6 address.
The question I have for this forum is what is the MTU value that should be set
for this Link Local address?
Possibilities:
1. 1280 --- the reason is that this value would guarantee a Neighbor
Discovery operation since all devices must support at least this MTU.
2
Hi John,
The specification reserves FE80::/10 for any link-local address
format. The only currently used instantiation is the FE80::/64 prefix.
In other words, a new RFC could define alternative formats for the
internal 54 bits underneath the FE80::/10 prefix.
Regards,
Brian
On Jul
John,
On Jul 11, 2006, at 12:11 PM, ext John Spence wrote:
2.5.6. Link-Local IPv6 Unicast Addresses
Link-Local addresses are for use on a single link. Link-Local
addresses have the following format:
| 10 |
| bits| 54 bits | 64 bits |
::", but then I would
> think we'd write that as "fe80::/64".
>
>
>
> So, do those middle 54 bits have to be zero, or can they be anything?
>
I ping6ed my Linux link-local address with those 54 bits equaling 0:
[EMAIL PROTECTED]:~$ ping6 -I eth1 fe80:0:0::2
Reading RFC 4291, I am not 100% clear on the format for
link-local addresses. In some places the document specifies “fe80::/10”,
which I read as “the first ten bits must be 1110 10, the remaining
54 bits can be anything, up to the /64 bit boundary . Later in the
document I see this:
Title: Recall: Link Local address
Ken Yi (xyi) would like to recall the message, "Link Local address".
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailma
Title: Recall: Please ignore: Link Local address
Ken Yi (xyi) would like to recall the message, "Please ignore: Link Local address".
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Reque
Title: Recall: Link Local address
Ken Yi (xyi) would like to recall the message, "Link Local address".
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailma
> -Original Message-
> From: Ken Yi (xyi)
> Sent: Thursday, March 16, 2006 5:30 PM
> To: ipv6@ietf.org
> Subject: Link Local address
>
> Hi,
>
> Per RFC-3513, link-Local addresses have the following format:
>
>| 10 |
>| bits|
|
+--+-++
Does it mean that the mid 54-bit must be 0 for a legitimate link-local
address?
Thanks,
Ken
> -Original Message-
> From: Eric Levy- Abegnoli (elevyabe)
> Sent: Tuesday, March 14, 2006 11:58 PM
> To: Jon R
> On Fri, 17 Jun 2005 21:12:03 +0300,
> Markku Savela <[EMAIL PROTECTED]> said:
> I have to keep using the "node-local scope", because implementation
> architecture puts it into good use internally.
> There is some difference in link local and node local:
> - link local addresses can ac
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
> <[EMAIL PROTECTED]>
> We should first note that the notion of "node local" scope was
> deprecated in RFC3513. But I suspect there is almost no difference in
> practice between (now deprecated) "node-local" and "link-local of
On Fri, 2005-06-17 at 08:16 +0300, Markku Savela wrote:
> > From: Bob Hinden <[EMAIL PROTECTED]>
>
> > Possibly, however from Section 2.5.3 "The Loopback Address" it says:
> >
> > The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
> > It may be used by a node to send an I
> From: Bob Hinden <[EMAIL PROTECTED]>
> Possibly, however from Section 2.5.3 "The Loopback Address" it says:
>
> The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
> It may be used by a node to send an IPv6 packet to itself. It must
> not be assigned to any physica
Jinmei,
Ah, yes, and I should have been more careful before sending the
message...RFC3513(addr-arch-v3) already has this change, which is not
in RFC2372 and is probably a result of the previous discussion.
Thanks for the clarification, and sorry about the noise.
No problem. I was glad to fin
> On Fri, 17 Jun 2005 08:16:50 +0300,
> Markku Savela <[EMAIL PROTECTED]> said:
>> Possibly, however from Section 2.5.3 "The Loopback Address" it says:
>>
>> The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
>> It may be used by a node to send an IPv6 packet to itself.
> On Thu, 16 Jun 2005 16:56:27 -0700,
> Bob Hinden <[EMAIL PROTECTED]> said:
>> All interfaces are required to have at least one link-local unicast
>> address (see Section 2.8 for additional required addresses).
>>
>> (this should be generally interpreted that even the loopback interface
architecture document. In a previous discussion
back in 2002, we seem to have agreed the loopback interface does not
have to have a link-local address (with the "fe80::/10" prefix):
http://www.atm.tut.fi/list-archive/ipng/msg02583.html
...despite the requirement in Section 2.1 of
draft
1 - 100 of 118 matches
Mail list logo
