headers
Suresh Krishnan | 2 Aug 2006 21:17
Picon
Favicon

Comments on draft-haberman-ipv6-ra-flags-option-00.txt

Hi Bob and Brian,

   Thanks for writing this document. I read this and I feel it is a 
simple and effective way to extend the flags in a RA. I appreciate the 
fact that it does not take away 1 bit from the original RA flags to 
indicate the presence of this option.

Minor comment:
The following text in RFC2461 section 6.1.2 may need to be updated to 
accommodate this option.
"The contents of any defined options that are not specified to be used
  with Router Advertisement messages MUST be ignored and the packet
  processed as normal.  The only defined options that may appear are
  the Source Link-Layer Address, Prefix Information and MTU options.
  An advertisement that passes the validity checks is called a "valid
  advertisement".

   In a slightly related note, I feel that any document which is 
assigned one of these flags MUST be indicated as updating the ND 
specification (RFC2461/RFC2461bis). If this is not done it is highly 
likely people would assume that those bits are unallocated. e.g. 
RFC3775, RFC4191 and RFC4389 use these flag bits but do not update 
RFC2461. So a new draft author may wrongly assume the bit to be 
available for use. I saw a presentation in the 16ng meeting where the 
authors were trying to reuse the MIPv6 Home agent bit for their proposal.

I DO LIKE the idea of the IANA registry for these bits, but until that 
is setup we may still have issues with people using conflicting bits. In 
the meantime, is it possible for the ipv6 wg to be the "guardian" :-) 
for these bits? The dna working group is working on a protocol which
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 3 Aug 2006 16:03
Picon
Favicon

Re: draft-narten-ipv6-3177bis-48boundary-02.txt

Mark Smith wrote:
> Hi Kurtis,
> 
> On Tue, 25 Jul 2006 19:36:02 +0200
> Kurt Erik Lindqvist <kurtis <at> kurtis.pp.se> wrote:
> 
> 
>>On 25 jul 2006, at 12.16, Mark Smith wrote:
>>
>>
>>>Hi Kurtis,
>>>
> 
> <snip>
> 
>>There are two problems here. 1) I am pretty convinced that the IETF  
>>shouldn't be running address-policy for the ISPs. Especially since  
>>there are also complexity here that I am not sure we understand (i.e  
>>RIR -> LIR charging schemes).
> 
> 
> I agree with that. RFC3177 seems to be a IESG/IAB recommendation /
> Informational RFC. If ISPs / RIRs etc. don't follow the recommendation,
> then it's probably useful for the IETF to point out the technical pros
> and cons of their decision.

I think we have some responsibility beyond just pointing out pros
and cons. The reason I think that the /48 recommendation is OBE is
not that I think it's a mistake - but it's clear that (some) operators
and (some) registries are being very cautious about handing out IPv6
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Hinden | 4 Aug 2006 10:19
Picon

Re: Comments on draft-haberman-ipv6-ra-flags-option-00.txt

Suresh,

On Aug 2, 2006, at 12:17 PM, ext Suresh Krishnan wrote:

> Hi Bob and Brian,
>
>   Thanks for writing this document. I read this and I feel it is a  
> simple and effective way to extend the flags in a RA. I appreciate  
> the fact that it does not take away 1 bit from the original RA  
> flags to indicate the presence of this option.

Thanks.

> Minor comment:
> The following text in RFC2461 section 6.1.2 may need to be updated  
> to accommodate this option.
> "The contents of any defined options that are not specified to be used
>  with Router Advertisement messages MUST be ignored and the packet
>  processed as normal.  The only defined options that may appear are
>  the Source Link-Layer Address, Prefix Information and MTU options.
>  An advertisement that passes the validity checks is called a "valid
>  advertisement".

My reading of that paragraph is that it is discussing options that  
are not intended for RA messages.  If a new option says it defined  
for RA messages, then it would pass this test and be processed.  We  
could add some text to the draft that says that the new option is for  
RA messages and is valid.

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Austein | 6 Aug 2006 06:00
Favicon

Weekly posting summary for ipv6 <at> ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 12.50% |    1 | 18.73% |     7649 | brc <at> zurich.ibm.com
 12.50% |    1 | 16.01% |     6538 | bob.hinden <at> nokia.com
 12.50% |    1 | 14.78% |     6033 | alexandru.petrescu <at> motorola.com
 12.50% |    1 | 13.04% |     5324 | suresh.krishnan <at> ericsson.com
 12.50% |    1 | 11.88% |     4849 | fred.l.templin <at> boeing.com
 12.50% |    1 | 10.48% |     4279 | sra+ipng <at> hactrn.net
 12.50% |    1 | 10.36% |     4231 | mailman-owner <at> ietf.org
 12.50% |    1 |  4.72% |     1926 | vno <at> teamlog.com
--------+------+--------+----------+------------------------
100.00% |    8 |100.00% |    40829 | 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
z i | 7 Aug 2006 20:00
Picon
Favicon

IPv6 Deployment Status

Hello,

I want to find a summary (soft copy) of current deployment status of IPv6 in world wide, including IPv4/IPv6.

Can somebody help me with that?

thanks,
Zohar

Yahoo! Music Unlimited - Access over 1 million songs. Try it free. 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Basavaraj Patil | 8 Aug 2006 05:33
Picon

Proposal to change aspects of Neighbor Discovery


Hello,

The I-D: 
http://www.ietf.org/internet-drafts/draft-madanapalli-ipv6-periodic-rtr-advt
s-00.txt

proposes several changes to ND procedures and parameters.

Pls review and comment.

-Raj

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 67 comments |
headers
Mohacsi Janos | 8 Aug 2006 08:37
Picon
Favicon

Re: Proposal to change aspects of Neighbor Discovery


On Mon, 7 Aug 2006, Basavaraj Patil wrote:

>
> Hello,
>
> The I-D:
> http://www.ietf.org/internet-drafts/draft-madanapalli-ipv6-periodic-rtr-advt
> s-00.txt
>
> proposes several changes to ND procedures and parameters.
>
> Pls review and comment.

Can you justify with power consumptions this proposal?
- In avarage how much energy do you need to send out a router solicitation 
message?
- In avarage how much energy do you need to maintain cellular conection 
while you are moving  - let say in an office?

Thanks,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Lawrence Zou | 8 Aug 2006 10:46
Favicon

a question about ULA

 when i read RFC4193,I found it does not mentioned what should do when the
router that produced the ULA global ID  reboot.  
Does it will produce another pseudo-random  global id  or it will  recover
the global id that it produced before it reboot?

I ask this question because i think that in a site,it is very probably that
sometimes  the device have to  be rebooted,  if each time the rebooted
router 
produce a new ULA global id,all devices that attached to the router have to
renumbered , i do not think it is a happy  process.

Best regards,

Lawrence 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 7 comments |
headers
Remi Denis-Courmont | 8 Aug 2006 10:57

Re: a question about ULA

Selon Lawrence Zou <zou.rong <at> huawei.com>:

>  when i read RFC4193,I found it does not mentioned what should do when the
> router that produced the ULA global ID  reboot.
> Does it will produce another pseudo-random  global id  or it will  recover
> the global id that it produced before it reboot?

You are not supposed to change your ULA prefix.
The reason why the specification refers to pseudo-random is to discourage
people from using meaningful values, as these would be much more likely to
collide.

This pseudo-random generation is supposed to be a ONE TIME operation for the
whole entity/network. It should never (or only on very special occasions)
have to change. ULA would be very impractical if these were changing; in
particular, storing addresses in DNS would be quite difficult.

--

-- 
Remi Denis-Courmont
http://www.simphalempin.com/home/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Mohacsi Janos | 8 Aug 2006 10:56
Picon
Favicon

Re: a question about ULA


On Tue, 8 Aug 2006, Lawrence Zou wrote:

> when i read RFC4193,I found it does not mentioned what should do when the
> router that produced the ULA global ID  reboot.
> Does it will produce another pseudo-random  global id  or it will  recover
> the global id that it produced before it reboot?
>
> I ask this question because i think that in a site,it is very probably that
> sometimes  the device have to  be rebooted,  if each time the rebooted
> router
> produce a new ULA global id,all devices that attached to the router have to
> renumbered , i do not think it is a happy  process.

This is not the expected operation. I believe more suitable is: site 
administrator generates a pseudo-random global id and configures on 
the routers. ULA does not give automatic router configuration...
Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

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

Gmane