Rob Austein | 2 Jul 06:00 2006
Picon

Weekly posting summary for ipv6 <at> ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 10.00% |    1 | 15.92% |    11744 | jinmei <at> wide.ad.jp
 10.00% |    1 | 14.22% |    10489 | jjeong <at> cs.umn.edu
 10.00% |    1 | 11.17% |     8236 | adamson <at> us.ibm.com
 10.00% |    1 | 11.10% |     8191 | fred.l.templin <at> boeing.com
 10.00% |    1 | 10.62% |     7832 | haibo.wen <at> alcatel-sbell.com.cn
 10.00% |    1 |  9.78% |     7214 | pekkas <at> netcore.fi
 10.00% |    1 |  8.94% |     6596 | timbeck04 <at> verizon.net
 10.00% |    1 |  7.57% |     5583 | alun <at> cisco.com
 10.00% |    1 |  5.74% |     4232 | mailman-owner <at> ietf.org
 10.00% |    1 |  4.95% |     3649 | sra+ipng <at> hactrn.net
--------+------+--------+----------+------------------------
100.00% |   10 |100.00% |    73766 | 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
--------------------------------------------------------------------

Bob Hinden | 3 Jul 22:18 2006
Picon

Re: Forward: Re: Last Call: 'IPv6 Router Advertisement Option for DNS Configuration' to Experimental RFC (draft-jeong-dnsop-ipv6-dns-discovery)

Tatuya,

On Jun 29, 2006, at 9:52 PM, ext JINMEI Tatuya / 神明達哉 wrote:

> Resending to the list with the source address that appears to be
> expected (the original message seems to have been filtered)...
>
> This time I'm also copying the ipv6 list.  In fact, ipv6 <at> ietf would be
> more suitable place for discussions on this proposal, since it's an
> extension to ND.

I agree and removed the cc: to DNSOP in this reply.

>
> I have several comments on this draft:
>
> - A meta level comment
>
>   I'm afraid I'm re-raising an old discussion (in which case I hope
>   someone will point it out), but I'm concerned that this document may
>   open up a possibility of making (autoconfiguration via) Router
>   Advertisement a convenient and uncontrollable kitchen sink.  In my
>   understanding, the applicability of RA in the original design was
>   limited to a minimum number of layer-3 configuration information
>   parameters, such as subnet prefixes and default router addresses.
>   If my understanding is correct and the design principle still
>   applies, the proposed option is (IMO) against the principle because
>   the configuration information provided by this document (i.e.,
>   recursive DNS server addresses) is (again IMO) at a far higher layer
>   than the intended one.  And the standardization of this option will
(Continue reading)

Pars Mutaf | 7 Jul 14:04 2006
Picon

Re: interface ID from human name how to?

Hello,

Thanks for your reply. 
Please see below:

On Fri, 2006-06-23 at 15:11 -0700, Bob Hinden wrote:
> Hi,
> 
> On Jun 8, 2006, at 4:35 AM, ext Pars Mutaf wrote:
> 
> >
> > Hello,
> >
> > Is there a standard way of constructing
> > an interface ID from human name?
> 
> Ignoring for now if this is good or bad idea, but you might look at
> 
>    http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name- 
> lookups-15.txt

It looks like ICMP name lookups can also be used to do the same thing.
However, I couldn't understand why I would use a side protocol
(i.e. an ICMP protocol).

My proposal uses basic IPv6. BTW, the draft is now available at 
the IETF site:
http://www.ietf.org/internet-drafts/draft-mutaf-ipv6humid-00.txt

> There is a mechanism there to create multicast addresses based on a  
(Continue reading)

Bob Hinden | 7 Jul 19:43 2006
Picon

Re: interface ID from human name how to?

Pars,

>> Ignoring for now if this is good or bad idea, but you might look at
>>
>>    http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-
>> lookups-15.txt
>
>
> It looks like ICMP name lookups can also be used to do the same thing.
> However, I couldn't understand why I would use a side protocol
> (i.e. an ICMP protocol).
>
> My proposal uses basic IPv6. BTW, the draft is now available at
> the IETF site:
> http://www.ietf.org/internet-drafts/draft-mutaf-ipv6humid-00.txt
>

My suggestion was to look at the mechanisms in this document.  It a  
lot more specific than just saying "hash(John Smith)".

>> There is a mechanism there to create multicast addresses based on a
>> host name that might be a starting point.
>>>
>>> I would like to configure an interface ID
>>> hash(ParsMutaf| 1) and if it collides
>>> hash(ParsMutaf| 2) etc..
>>>
>>> You can try reach or locate me
>>> by sending a packet to (please do not
>>> hesitate):
(Continue reading)

Pars MUTAF | 8 Jul 21:43 2006
Picon

Re: interface ID from human name how to?


Hello,

For example, we are in the same campus. The campus is covered
by a single subnet with several wireless access points. I need
to call you. But there is a problem and I can't get the IPv6 address
of your cellular phone (DNS, or MIPv6 home agent failure).

But, I suspect
that you are probably in the campus (because you work here).
Since we are in the same campus (and, in this example, in the same
subnet), we are receiving the same router advertisements. Consequently,
I know your subnet prefix. I also know your name, then
I can construct your HUMID (interface ID based on HUMan name).
It is: 64bithash(Bob Hinden). Then, I can reach you (if you're really
in the campus).

Now, imagine a different campus. This campus is covered by 5
subnets. I work in this
campus. In the past I visited different
parts of the campus, and my phone recorded all of the subnet prefixes
that it received from the routers (in the recent past). My phone
has now the list of subnets that cover the subnet (more or less).

I suspect that you're currently in the campus. But I am
not sure which part of it. I know your name. I can construct
your HUMID. My phone has a list of 5 locations (subnets) where you
(and your phone) is likely to be found. It sends a packet to the
IPv6 addresses:

(Continue reading)

Rob Austein | 9 Jul 06:00 2006
Picon

Weekly posting summary for ipv6 <at> ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 40.00% |    2 | 53.19% |    20073 | pars.mutaf <at> int-evry.fr
 40.00% |    2 | 36.09% |    13618 | bob.hinden <at> nokia.com
 20.00% |    1 | 10.72% |     4044 | sra+ipng <at> hactrn.net
--------+------+--------+----------+------------------------
100.00% |    5 |100.00% |    37735 | 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
--------------------------------------------------------------------

Peter Sherbin | 11 Jul 02:04 2006
Picon

Re: interface ID from human name how to?

Pars,

Why would you need IETF to tell you which human name format to use. Technically any
and all bits to the right of the network boundary are yours and you can do with them
whatever you want.

Thanks,

Peter

--- Pars MUTAF <Pars.Mutaf <at> int-evry.fr> wrote:

> 
> Hello,
> 
> For example, we are in the same campus. The campus is covered
> by a single subnet with several wireless access points. I need
> to call you. But there is a problem and I can't get the IPv6 address
> of your cellular phone (DNS, or MIPv6 home agent failure).
> 
> But, I suspect
> that you are probably in the campus (because you work here).
> Since we are in the same campus (and, in this example, in the same
> subnet), we are receiving the same router advertisements. Consequently,
> I know your subnet prefix. I also know your name, then
> I can construct your HUMID (interface ID based on HUMan name).
> It is: 64bithash(Bob Hinden). Then, I can reach you (if you're really
> in the campus).
> 
> Now, imagine a different campus. This campus is covered by 5
(Continue reading)

Pars Mutaf | 11 Jul 11:17 2006
Picon

Re: interface ID from human name how to?

On Mon, 2006-07-10 at 17:04 -0700, Peter Sherbin wrote:
> Pars,
> 
> Why would you need IETF to tell you which human name format to use. Technically any
> and all bits to the right of the network boundary are yours and you can do with them
> whatever you want.

Hi, 

That's right, we can do whatever we want. However:

If my host configures an interface ID from 64bithash(pars mutaf), 
but someone tries to reach me at 64bithash(parsmutaf),
this won't work.. A standard human name format is needed.  

(is this off-topic?)

pars

> 
> Thanks,
> 
> Peter
> 
> --- Pars MUTAF <Pars.Mutaf <at> int-evry.fr> wrote:
> 
> > 
> > Hello,
> > 
> > For example, we are in the same campus. The campus is covered
(Continue reading)

John Spence | 11 Jul 18:11 2006

Seeking clarifying information on RFC 4291 and link-local address format ...

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 1111 1110 10, the remaining 54 bits can be anything, up to the /64 bit boundary .  Later in the document I see this:

 

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           |

   +----------+-------------------------+----------------------------+

   |1111111010|           0             |       interface ID         |

 

Which I read as “the first 64 bits are always fe80::”, 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?

 

Thanks for any insight.

 

 

John SpenceCommand Information

spence <at> commandinformation.com

 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Pars MUTAF | 11 Jul 21:26 2006
Picon

Re: Seeking clarifying information on RFC 4291 and link-local address format ...


Hello,

Selon John Spence <spence <at> commandinformation.com>:

> 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 1111 1110 10, the remaining 54 bits
> can be anything, up to the /64 bit boundary .  Later in the document I
> see this:
>
>
>
> 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           |
>    +----------+-------------------------+----------------------------+
>    |1111111010|           0             |       interface ID         |
>
>
>
> Which I read as "the first 64 bits are always fe80::", 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:

pars <at> lazylizard:~$ ping6 -I eth1 fe80:0:0::2c0:9fff:feef:ffb4
PING fe80:0:0::2c0:9fff:feef:ffb4(fe80::2c0:9fff:feef:ffb4) from
fe80::2c0:9fff:feef:ffb4 eth1: 56 data bytes
64 bytes from fe80::2c0:9fff:feef:ffb4: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from fe80::2c0:9fff:feef:ffb4: icmp_seq=2 ttl=64 time=0.034 ms

Then, I tried to ping6 my link-local address by modifying some of
your 54 bits:

pars <at> lazylizard:~$ ping6 -I eth1 fe80:0:1::2c0:9fff:feef:ffb4
connect: Network is unreachable
pars <at> lazylizard:~$

Looks like Linux likes them when they are zero.
:-/
I'm not sure what this means. I hope this helps.

Regards,
pars

>
>
> Thanks for any insight.
>
>
>
>
>
> John Spence, Command Information
>
> spence <at> commandinformation.com <mailto:spence <at> commandinformation.com>
>
>
>
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

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


Gmane