headers
JINMEI Tatuya / 神明達哉 | 1 Nov 2006 07:34
Picon

Re: Link Local Address

>>>>> On Fri, 13 Oct 2006 15:02:19 +0800, 
>>>>> "Hanamantapppa Yuvraj-A21366" <yuvraj.saunshi <at> motorola.com> said:

> 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?

I don't know the background of the question, but I guess no one blames
you if the router does not forward packets while the (only) IPv6
address configured on the outgoing interface is in the tentative
state.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei <at> isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
Leon | 1 Nov 2006 08:06
Favicon

Re: Link Local Address

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 / 神明達哉" <jinmei <at> isl.rdc.toshiba.co.jp>
To: "Hanamantapppa Yuvraj-A21366" <yuvraj.saunshi <at> motorola.com>
Cc: <ipv6 <at> ietf.org>
Sent: Wednesday, November 01, 2006 2:34 PM
Subject: Re: Link Local Address


>>>>>> On Fri, 13 Oct 2006 15:02:19 +0800, 
>>>>>> "Hanamantapppa Yuvraj-A21366" <yuvraj.saunshi <at> motorola.com> said:
> 
>> 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?
> 
> I don't know the background of the question, but I guess no one blames
> you if the router does not forward packets while the (only) IPv6
> address configured on the outgoing interface is in the tentative
> state.
> 
> JINMEI, Tatuya
(Continue reading)

Permalink | Reply | 0 comments |
headers
Soliman, Hesham | 1 Nov 2006 08:00

RE: Last Call: 'Neighbor Discovery for IP version 6 (IPv6)' to Draft Standard (draft-ietf-ipv6-2461bis)

ok, sounds good to me, which  means we have no open issues on the draft. 

Hesham

 > -----Original Message-----
 > From: Basavaraj Patil [mailto:basavaraj.patil <at> nokia.com] 
 > Sent: Wednesday, November 01, 2006 2:51 AM
 > To: ext JINMEI Tatuya / 神明達哉 ; Soliman, Hesham
 > Cc: ipv6 <at> ietf.org; Thomas Narten
 > Subject: Re: Last Call: 'Neighbor Discovery for IP version 6 
 > (IPv6)' to Draft Standard (draft-ietf-ipv6-2461bis) 
 > 
 > 
 > Hesham,
 > 
 > I like Jinmei's proposal of rejecting the issue as far as 
 > changing 2461bis
 > value goes. Because even the Max value of 2999 seconds is 
 > still not good
 > enough for some links.
 > 
 > So I think it is best to let IPv6 over foo specific 
 > documents specify what
 > router configuration variables are modified or over-ridden 
 > (from the default
 > 2461bis). 
 > 
 > -Basavaraj
 > 
 >
(Continue reading)

Permalink | Reply | 501 comments |
headers
Templin, Fred L | 1 Nov 2006 18:20
Picon
Favicon

RE: Question about "on-link" in RFC2461(bis)

After discussion with authors (see attachments), I am
now convinced that there is no issue with the text as
it stands and am withdrawing the comment. If anyone
feels differently, please follow-up on the list.

Thanks - Fred
fred.l.templin <at> boeing.com

-----Original Message-----
From: Templin, Fred L 
Sent: Thursday, October 26, 2006 4:10 PM
To: ipv6 <at> ietf.org
Subject: Question about "on-link" in RFC2461(bis)

I have a question about on-link determination for IPv6 ND.
(RFC2461(bis), Section 2.1) has the following definition
for on-link:

  "on-link - an address that is assigned to an interface on a
             specified link. A node considers an address to be on-
             link if:

           - it is covered by one of the link's prefixes, or

           - a neighboring router specifies the address as
             the target of a Redirect message, or

           - a Neighbor Advertisement message is received for
             the (target) address, or
(Continue reading)

Permalink | Reply | 0 comments |
headers
kernel learner | 2 Nov 2006 11:24
Picon

IPv6-Link local address

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 interface identifier. why some bits are removed like this? and they are not considered in checksum calculation also. why?

Thanks n Regards 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
David Malone | 2 Nov 2006 14:51
Picon
Picon
Favicon

Re: IPv6-Link local address

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 is it done?

> Acc. to rfc, those 16bits are part of 64 bit interface identifier. why some
> bits are removed like this? and they are not considered in checksum
> calculation also. why?

How are you observing these packets? On some implementations the
interface identifier is written into unused bits of link-local
addresses. However these bits should be cleared before the packet
is transmitted, and so are not present when the checksum is calculated.

If you observe these packets in the IPv6 stack, you may see these
extra bits set. If you observe them after they have left the IPv6
stack (say with tcpdump, which would usually see packets at the
driver level) then you should not see these bits set. I've included
to packets grabbed with tcpdump below.

[This list may not be the best place to ask this question - it sounds
like you are asking about a particular IPv6 implementation and a list
relating to that implementation may be a better choice.]

	David.

13:41:46.897988 IP6 fe80::213:72ff:fe50:32d5 > fe80::20d:56ff:fe22:320c: ICMP6, neighbor
solicitation, who has fe80::20d:56ff:fe22:320c, length 32
        0x0000:  6000 0000 0020 3aff fe80 0000 0000 0000  `.....:.........
        0x0010:  0213 72ff fe50 32d5 fe80 0000 0000 0000  ..r..P2.........
        0x0020:  020d 56ff fe22 320c 8700 1e39 0000 0000  ..V.."2....9....
        0x0030:  fe80 0000 0000 0000 020d 56ff fe22 320c  ..........V.."2.
        0x0040:  0101 0013 7250 32d5                      ....rP2.
13:41:46.898077 IP6 fe80::20d:56ff:fe22:320c > fe80::213:72ff:fe50:32d5: ICMP6, neighbor
advertisment, tgt is fe80::20d:56ff:fe22:320c, length 24
        0x0000:  6000 0000 0018 3aff fe80 0000 0000 0000  `.....:.........
        0x0010:  020d 56ff fe22 320c fe80 0000 0000 0000  ..V.."2.........
        0x0020:  0213 72ff fe50 32d5 8800 837a 4000 0000  ..r..P2....z <at> ...
        0x0030:  fe80 0000 0000 0000 020d 56ff fe22 320c  ..........V.."2.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Templin, Fred L | 3 Nov 2006 01:09
Picon
Favicon

Multilink subnet issues and proxy/relay DAD

The question of proxy/relay DAD for multilink networks that
comprise shared links has come up on the NETLMM and Autoconf
mailing lists. Proxy/relay DAD is a mechanism whereby NS(DAD)
messages are relayed to the link on which a node with a
colliding address resides, with the colliding node's NA(DAD)
being relayed back to the link on which the soliciting node
resides. (The Target Link Layer Address Option in the relayed
NA(DAD) must not be changed by the relays to ensure proper
SEND operation in this process.)

James Kempf has twice indicated that there have been prior
discussions on this subject between Jari Arkko and Dave
Thaler, and that they should be consulted for further
information (see below), but several attempts to contact
them have so far produced no results.

To ensure a fair and open dialogue at IETF67, I am requesting
that Jari, Dave, James and others with firsthand information
address the following questions on the lists prior to the
meetings:

  1. What are the issues wrt proxy/relay DAD that would
     interfere with its adoption as a standard mechanism?
  2. What harmful on-link assumptions could there be for
     IPv6 Prefix Information Options that advertise a
     shared prefix with 'L=0'?
  3. Does the RFC1812 "subnet forwarding model" still apply
     to IPv6, when there are no IPv6 documents that reference
     RFC1812 normatively?
  4. What other non-obvious issues relating to multilink
     subnets for shared links need to be observed for NETLMM,
     Autoconf and other contexts?

Fred Templin
fred.l.templin <at> boeing.com     

-----Original Message-----
From: James Kempf [mailto:kempf <at> docomolabs-usa.com] 
Sent: Wednesday, November 01, 2006 1:50 PM
To: Templin, Fred L; Behcet Sarikaya; Alexandru Petrescu
Cc: netlmm <at> ietf.org
Subject: Re: How does "per-MN prefix model" simplify things? (was:
RE:[netlmm]Re: PMIP follow-up questions)

>You mentioned a while back that there were some discussions
>involving IAB and/or IESG members that indicated there might
>be some barrier to acceptance of a proxy/relay DAD solution.
>Can you say anything more about that?

Primarily DaveT's multi-link subnet draft. I think it would be prudent
to 
discuss the issue with him before the WG makes a decision. Also, I think
we 
should check with Jari to find out what he thinks. It is necessary that
Jari 
agree with anything the WG comes up with if we are to get IESG approval.

            jak 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Samita Chakrabarti | 3 Nov 2006 10:08
Picon

Re: address selection and DHCPv6

> Overall, it seems to me this issue (if we want to handle it in normal
> operation) is a matter of policy and beyond the scope of *default*
> selection rule.  For example, if we really want to mix addresses
> configured vi DHCPv6 and addresses configured via SAAC, and want to
> prefer (e.g.) the former to the latter, (again, as others pointed out)
> we could differentiate the prefixes for these addresses and control
> the preference by distributing the policy table via (e.g.) a DHCPv6
> option proposed in draft-fujisaki-dhc-addr-select-opt-00.  Or,
> espically in case of DHCPv6, we may even do that without separating
> the prefixes by specifying the allocated address itself as a /128
> "prefix" for the address selection policy DHCPv6 option.  This way, we
> can use the same DHCPv6 message(es) to allocate the address with the
> address selection preference.
>

While we are discussing the topic of different kind of sytem-wide
address selection
(such as DHCPv6 or AUTOCONF), I'd like to point out that, optionally
new type of choices
could be implemented at the socket application level  by adding a few new flags
in IPv6 source address selection api
(draft-chakrabarti-ipv6-addrselect-api-04.txt).

-Samita

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Rob Austein | 5 Nov 2006 01:00
Favicon

Weekly posting summary for ipv6 <at> ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 10.00% |    2 | 32.17% |    50420 | fred.l.templin <at> boeing.com
 15.00% |    3 | 11.30% |    17703 | jinmei <at> isl.rdc.toshiba.co.jp
 10.00% |    2 |  6.87% |    10762 | pars.mutaf <at> int-evry.fr
  5.00% |    1 |  5.46% |     8563 | hardie <at> qualcomm.com
  5.00% |    1 |  5.36% |     8394 | hsoliman <at> qualcomm.com
  5.00% |    1 |  4.83% |     7568 | basavaraj.patil <at> nokia.com
  5.00% |    1 |  4.10% |     6421 | santosh_k_itkare <at> yahoo.co.in
  5.00% |    1 |  4.04% |     6326 | liangru <at> huawei.com
  5.00% |    1 |  3.82% |     5988 | jari.arkko <at> piuha.net
  5.00% |    1 |  3.48% |     5451 | dwmalone <at> maths.tcd.ie
  5.00% |    1 |  3.42% |     5354 | kernellearner <at> gmail.com
  5.00% |    1 |  3.31% |     5186 | pekkas <at> netcore.fi
  5.00% |    1 |  3.23% |     5054 | sra+ipng <at> hactrn.net
  5.00% |    1 |  3.22% |     5039 | samitac2 <at> gmail.com
  5.00% |    1 |  2.72% |     4255 | mailman-owner <at> ietf.org
  5.00% |    1 |  2.70% |     4226 | suresh.krishnan <at> ericsson.com
--------+------+--------+----------+------------------------
100.00% |   20 |100.00% |   156710 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the IPv6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Jari Arkko | 5 Nov 2006 07:30

Re: Multilink subnet issues and proxy/relay DAD

Hi Fred,
>   1. What are the issues wrt proxy/relay DAD that would
>      interfere with its adoption as a standard mechanism?
>   
Almost anything can be made to work, but often
the question is what works best or with least
changes. In particular, we can make proxy DAD
work, probably even with SEND. But I would
still prefer an approach that does not require
that. Also, if you need proxy DAD, does that
mean that link local multicast does not work
on the link as expected?
>   2. What harmful on-link assumptions could there be for
>      IPv6 Prefix Information Options that advertise a
>      shared prefix with 'L=0'?
>   
None that I know of.
>   3. Does the RFC1812 "subnet forwarding model" still apply
>      to IPv6, when there are no IPv6 documents that reference
>      RFC1812 normatively?
>   4. What other non-obvious issues relating to multilink
>      subnets for shared links need to be observed for NETLMM,
>      Autoconf and other contexts?
>   
I am not sure I have an answer. But let me ask you a
question about something which has been unclear
to me during the NETLMM discussion. What is the
real-world functionality that you would like to have?
Media where this is needed? Employing just one
prefix per a number of hosts? Special requirements
on what the scope of link local multicast should be?

Also, my understanding of the NETLMM decision
is that the working group wants to limit initial
design to per-host prefix model, but that this
could be extended in the future.

As for AUTOCONF, there are no decisions yet,
but my main requirement for them has been
that they must define their architecture, including
addressing and how links are seen from IP. And
avoid issues from Dave's draft if possible. The
architecture needs to be concrete enough so
that we can determine what protocol work is
needed for, e.g., prefix allocation, prefix/address
uniqueness checking, and gateway selection.

--Jari

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |

Gmane