Subject: Re: ipv6 Digest, Vol 3, Issue 20

From: "Mohammed Hussain" <[email-masked]>
Date: Sat, 17 Jul 2004 08:29:17 +0530

Hi All ,
 Are we going to use the EUI-64  format for the MAC address or continue with
the present 48 bit address ?

Regards

Mohammed Hussain

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 16, 2004 9:44 PM
Subject: ipv6 Digest, Vol 3, Issue 20

> Send ipv6 mailing list submissions to
> [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/ipv6
> or, via email, send a message with subject or body 'help' to
> [email-masked]
>
> You can reach the person managing the list at
> [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ipv6 digest..."
>
>
> Today's Topics:
>
>    1. Re: Comments on RFC2462bis (Suresh Krishnan)
>    2. I-D ACTION:draft-ietf-ipv6-link-scoped-mcast-04.txt
>       ([email-masked])
>    3. [rfc2461bis issue 246] preferred lifetime > valid lifetime
>       (JINMEI Tatuya / ????)
>    4. Re: Comments on RFC2462bis (JINMEI Tatuya / ????)
>    5. Re: rfc 2373 - 2.5.1 Interface Identifiers (Brian E Carpenter)
>    6. summary of WGLC for 2462bis and next step (JINMEI Tatuya / ????)
>    7. Updated IPv6 WG Agenda (Brian Haberman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 15 Jul 2004 12:59:29 -0400 (EDT)
> From: Suresh Krishnan <[email-masked]>
> Subject: Re: Comments on RFC2462bis
> To: JINMEI Tatuya / ???? <[email-masked]>
> Cc: Suresh Krishnan <[email-masked]>, [email-masked]
> Message-ID:
> <[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Hi Jinmei,
>   I am happy with all the resolutions you proposed. I looked through the
> mailing list archives but I was not able to find the rationale behind
> picking 2 hours. Probably it is there so that we can miss 3 RAs at
> maximum intervals and still get a proper valid lifetime.
>
> Thanks
> Suresh
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 15 Jul 2004 15:23:11 -0400
> From: [email-masked]
> Subject: I-D ACTION:draft-ietf-ipv6-link-scoped-mcast-04.txt
> To: [email-masked]
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the IP Version 6 Working Group Working Group
of the IETF.
>
> Title : Link Scoped IPv6 Multicast Addresses
> Author(s) : J. Park, et al.
> Filename : draft-ietf-ipv6-link-scoped-mcast-04.txt
> Pages : 7
> Date : 2004-7-15
>
> This document specifies an extension to the multicast addressing
>      architecture of the IPv6 protocol. The extension allows for the use
>      of interface-IDs to allocate multicast addresses.  When the link-
>      local unicast address is configured at each interface of a host, an
>      interface ID is uniquely determined.  By delegating multicast
>      addresses at the same time as the interface ID, each host can
>      identify their multicast addresses automatically at Layer 1 without
>      running an intra- or inter-domain allocation protocol in serverless
>      environments. Basically, it is preferred to use this method for the
>      link-local scope rather than Unicast-Prefix-based IPv6 Multicast
>      Addresses [RFC 3306].
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-04.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the
message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ipv6-link-scoped-mcast-04.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ipv6-link-scoped-mcast-04.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> -------------- next part --------------
> Skipped content of type multipart/alternative
>
> ------------------------------
>
> Message: 3
> Date: Fri, 16 Jul 2004 17:37:04 +0900
> From: JINMEI Tatuya / ???? <[email-masked]>
> Subject: [rfc2461bis issue 246] preferred lifetime > valid lifetime
> To: [email-masked]
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII
>
> Hello,
>
> I have a comment on issue 246 of rfc2461bis (preferred lifetime >
> valid lifetime).
>
> As far as I can see, the latest version of the draft
> draft-soliman-ipv6-2461-bis-01.txt introduces two changes for the
> issue:
>
> 1. Section 4.6.2 says:
>
>       Preferred Lifetime
>                      32-bit unsigned integer.  The length of time in
>                      seconds (relative to the time the packet is sent)
>                      that addresses generated from the prefix via
>                      stateless address autoconfiguration remain
>                      preferred [ADDRCONF].  A value of all one bits
>                      (0xffffffff) represents infinity. See [ADDRCONF].
> --->                 Note that the value of this field MUST NOT exceed
> --->                 the Valid Lifetime field to avoid preferring
> --->                 addresses that are no longer valid.
>
> 2. Section 6.2.1 says:
>
>       AdvPrefixList
>   [...]
>                         AdvPreferredLifetime
>   [...]
>                              Default: 604800 seconds (7 days), fixed
>                              (i.e., stays the same in consecutive
> --->                         advertisements). This value MUST NOT be
> --->                         larger than AdvValidLifetime.
>
>
> As I said in a related discussion for rfc2462bis, the change in
> Section 4.6.2 seems overspecification according to the original
> consensus that led to the issue.  See
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg03034.html
> for more details.  As I mentioned in this message, I think the
> restriction in Section 4.6.2 (the part marked with "---->") should be
> removed.
>
> Additionally, it is probably not enough to say "AdvPreferredLifetime
> MUST NOT be larger than AdvValidLifetime", since either one or both of
> the lifetimes can be configured so that it decrements in real
> time.  For example, consider the case where
>
>   AdvValidLifetime     = 40000 (decrementing in real time)
>   AdvPreferredLifetime = 30000 (fixed time).
>
> These configurations seem valid according to the specification.
> However, the advertised valid lifetime would be smaller than the
> advertised preferred lifetime about 10000 seconds later.
>
> I see two resolutions to avoid this scenario:
>
> A. if AdvValidLifetime decrements in real time, require
>    AdvPreferredLifetime decrement as well
> B. require routers to ensure the valid lifetime be equal to or larger
>    than the preferred lifetime at sending time, regardless of the
>    values of AdvValidLifetime and AdvPreferredLifetime.
>
> Option A would require additional text in Section 6.2.1.  Option B
> would require additional specification in Section 6.2.3.
>
> I personally can live with either approach, but slightly prefer the
> latter one, since it will provide maximum configuration flexibility.
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [email-masked]
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 16 Jul 2004 17:40:25 +0900
> From: JINMEI Tatuya / ???? <[email-masked]>
> Subject: Re: Comments on RFC2462bis
> To: Suresh Krishnan <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII
>
> >>>>> On Thu, 15 Jul 2004 12:59:29 -0400 (EDT),
> >>>>> Suresh Krishnan <[email-masked]> said:
>
> >   I am happy with all the resolutions you proposed. I looked through the
> > mailing list archives but I was not able to find the rationale behind
> > picking 2 hours. Probably it is there so that we can miss 3 RAs at
> > maximum intervals and still get a proper valid lifetime.
>
> Okay, thanks for searching for the information.
>
> You're probably correct on the rationale, but I won't do anything on
> this in rfc2462bis since we do not have a specific pointer about the
> original intent (sorry about that).
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [email-masked]
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 16 Jul 2004 14:48:36 +0200
> From: Brian E Carpenter <[email-masked]>
> Subject: Re: rfc 2373 - 2.5.1 Interface Identifiers
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> I agree that the explanation in the RFC is as simple as can
> be written. In fairness to Nilesh, we should mention that this
> was a controversial choice at the time, but that is what the
> WG decided a number of years ago.
>
>     Brian
>
>
> JINMEI Tatuya wrote:
> >>>>>>On Sun, 04 Jul 2004 00:45:13 +0530,
> >>>>>>Nilesh Simaria <[email-masked]> said:
> >
> >
> >>I have a question about RFC- 2373, 2.5.1 Interface Identifiers.
> >
> >
> >>It says :
> >>"The motivation for inverting the "u" bit when forming the interface
> >>identifier is to make it easy for system administrators to hand
> >>configure local scope identifiers when hardware tokens are not
> >>available.  This is expected to be case for serial links, tunnel end-
> >>points, etc.  The alternative would have been for these to be of the
> >>form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
> >>::2, etc."
> >
> >
> >>I am not able to understand above paragraph of rfc-2373. Can someone
> >>please explain ?
> >
> >
> > I'm not able to understand which part of the paragraph you did not
> > understand...if we did not invert the "u" bit in the interface
> > identifier and wanted to assign the identifier manually (for whatever
> > reason), then we'd need to set the bit corresponding to the "u" bit
> > since the identifier should not be global unique.  As a result, we'd
> > end up having less-readable or less-convenient address like
> > 2001:db8::200:0:0:1 while we'd actually want to use a simpler form of
> > "2001:db8::1".
> >
> > BTW, the explanation is almost same as what is written in the
> > RFC...(again, I'm not able to understand which part of the paragraph
> > you did not understand).
> >
> > JINMEI, Tatuya
> > Communication Platform Lab.
> > Corporate R&D Center, Toshiba Corp.
> > [email-masked]
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 17 Jul 2004 00:33:26 +0900
> From: JINMEI Tatuya / ???? <[email-masked]>
> Subject: summary of WGLC for 2462bis and next step
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=US-ASCII
>
> The wg last call for draft-ietf-ipv6-rfc2462bis-02.txt has ended.
> I'll soon post a new revision of the draft mainly based on comments
> sent during the last call, and I believe the new revision will be
> ready to be submitted to the IESG.
>
> For those who are interested, the current snap of the next revision is
> available at:
>   http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-03.txt
>
> I'll do some editorial checks on it, and submit it by the final
> submission cutoff on July 19.
>
> (To make it sure I didn't miss anything) the comments/questions raised
> in the last call period are as follows:
>
> from itojun
>   http://www1.ietf.org/mail-archive/web/ipv6/current/msg02996.html
>
> from EricLKlein
>   http://www1.ietf.org/mail-archive/web/ipv6/current/msg03015.html
>
> from Dan Lanciani
>   http://www1.ietf.org/mail-archive/web/ipv6/current/msg03019.html
>
> from Suresh Krishnan
>   http://www1.ietf.org/mail-archive/web/ipv6/current/msg03022.html
>
> I believe we've already agreed on what to do (or not to do) for the
> comments.  The followings are a summary of expected changes in the
> next revision:
>
>    o  Clarified that it is IPv6 network operation that should be
>       disabled on failure of Duplicate Address Detection, and that the
>       rule should apply when the hardware address is supposed to be
>       unique.
>    o  Changed the reference on the algorithm of computing solicited-node
>       multicast addresses to [RFC3513].
>    o  Made the intent clearer in the clarification that unicasted NS or
>       NA should be discarded during DAD.
>
> In addition to them, I've updated the boilerplate to the latest one as
> well as some minor editorial changes.
>
> Finally, I've noticed there may be some possible issues, but right now
> I don't think we need to do something on (one of) them (and thus they
> cannot be a showstopper).  Those are:
>
> - rfc2462bis will not support any form of the mixed host/router
>   behavior.  While a similar issue for rfc2461bis is under discussion,
>   I don't think we need to do anything for rfc2462bis at this stage on
>   this.  In fact, I've confirmed this policy (i.e., not supporting the
>   notion) several times on this list to be sure.
>
> - how to address the IAB recommendation about the prefix length for
>   starting with binary 000.  I've sent a question on this to the IAB
>   (with my proposal):
>     http://www1.ietf.org/mail-archive/web/ipv6/current/msg03027.html
>   but I've not seen any response to it.  Perhaps they are too busy as
>   usual, but even if so, I don't think the lack of response is a
>   showstopper at this stage.  If I actually needed to do something on
>   this, the IESG will at least point it out.
>
> - the current draft of rfc2462bis implicitly assumes that the prefix
>   length for on-link determination (specified in rfc2461bis) can take
>   an arbitrary value.  if rfc2461bis takes a different position on
>   this, rfc2462bis will need to be modified on this.  But in my
>   understanding rfc2461bis will be consistent with this assumption
>   (even if not, the necessary modification to rfc2462bis would be
>   minor)
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [email-masked]
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 16 Jul 2004 11:36:59 -0400
> From: Brian Haberman <[email-masked]>
> Subject: Updated IPv6 WG Agenda
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Comments/Additions/Corrections welcome...
>
>   Wednesday (08/04/04) 1530-1730
>   ------------------------------
>       * Intro & Agenda Bashing                chairs           3 minutes
>       * Document Status                       chairs           2 minutes
>       * IPv6 Plugtest Announcement            Guillemin        5 minutes
>       * 2461bis                               Soliman         10 minutes
>            - draft-soliman-ipv6-2461-bis-01.txt
>            - Goal: status update
>       * 2462bis                               Tatuya          10 minutes
>            - draft-ietf-ipv6-rfc2462bis-02.txt
>            - Goal: status update
>       * ICMP Updates                          Gupta/Hinden    15 minutes
>            - draft-ietf-ipngwg-icmp-v3-03.txt
>            - Goal: status update
>       * Optimistic DAD                        N. Moore        10 minutes
>            - draft-ietf-ipv6-optimistic-dad-01.txt
>            - Goal: status update
>       * M&O Flags in RA's                     Park             5 minutes
>            - draft-daniel-ipv6-ra-mo-flags-00.txt
>            - Goal: Raise awareness of work
>       * DNS configuration (RA option)         chairs          10 minutes
>            - draft-ietf-dnsop-ipv6-dns-configuration-01.txt
>            - Goal: Should the WG be doing something?
>       * Anycast Analysis                      chairs           5 minutes
>            - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt
>            - Goal: What to do?
>       * IPv6 over PPP update                  Varada          10 minutes
>            - draft-ietf-ipv6-over-ppp-v2-01.txt
>            - Goal: status update
>       * Link-scoped Multicast                 Shin            10 minutes
>            - draft-ietf-ipv6-link-scoped-mcast-04.txt
>            - Goal: Resolving open issues from WG Last Call
>       * IPv6 over WLAN/802.11                 chairs          20 minutes
>            - Goal: Should the WG be doing something?
>
>
>
>
> ------------------------------
>
> _______________________________________________
> ipv6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipv6
>
>
> End of ipv6 Digest, Vol 3, Issue 20
> ***********************************
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------