> The working group's work items are as follows:
>
> o Shepherd completion of standardization of RA Flags Option
> o Shepherd completion of standardization of the RH0 Deprecation
document
> o Complete documentation/standardization of IPv6 over PPP
Compression Negotiation
> o Compl
> -Original Message-
> From: Manfredi, Albert E [mailto:[EMAIL PROTECTED]
> My not-well-articulated point was: if everyone seems to have made RFC
> 1918 work quite well, why do we need to get overly precise in
> this time around?
I happen to work for a network that has to deal on a v
> -Original Message-
> From: David Conrad [mailto:[EMAIL PROTECTED]
> I thought "Site Locals" were deprecated because people
> couldn't agree on what a "site" was.
>
> > Are these ULA-Cs simply taking their place?
>
> That's my impression, but then again, I haven't see the
> revised
I do not have an issue (yet?) with the draft. I have an issue with the process
to create a draft about a very controversial issue in a wg that is not meeting
face to face.
- Alain.
- Original Message -
From: Brian Haberman <[EMAIL PROTECTED]>
To: Durand, Alain
Cc: Paul
> -Original Message-
> From: Paul Vixie [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 07, 2007 11:57 PM
> To: 'Ipv'
> Subject: Re: Revising Centrally Assigned ULA draft
>> > I say wrap it up and ship it.
>
> if that's what we're doing, then, i say kill it
This email exchange is t
Brian,
Give the heat this proposal is generating (at least in the ARIN region)
it does not seem very constructive to tackle this issue
in a sleeping working group that is not meeting face to face.
- Alain.
> -Original Message-
> From: Brian Haberman [mailto:[EMAIL PROTECTED]
> Sent:
I second the idea of an IANA registry for that. This would be
very useful and would provide be the easiest way to update that
list later.
- Alain.
> -Original Message-
> From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 21, 2007 1:43 AM
> To: ipv6@ietf.org
> Su
> -Original Message-
> From: Bob Hinden [mailto:[EMAIL PROTECTED]
> RFC2461, Section 4.2 says the following about new options:
>
>Future versions of this protocol may define new option types.
>Receivers MUST silently ignore any options they do not
> recognize
>
I would like to ask what is the transition plan for "legacy" IPv6 hosts
that do not implement this extension before I could consider this draft
a viable approach.
We have a number of bits that are currently defined that may be
questionable,
(the best example: O & M), so I would like to see some mo
I concur with the uselessness of the bits.
However, I've heard some implementers who where talking about
implementing extra code/logic to try to match what they thought the
semantic of those bits was/should be/should have been...
This is adding complexity, brittleness and opening doors to all kind
g I'd like to see hapening is the
source address selected by a server to change if one team changes a lifetime
without noticing the other...
- Alain.
- Original Message -
From: Bernie Volz (volz) <[EMAIL PROTECTED]>
To: Manfredi, Albert E <[EMAIL PROTECTED]>; Dura
> -Original Message-
> From: Gray, Eric [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 26, 2006 4:27 PM
> To: Durand, Alain
> Cc: ipv6@ietf.org; James Carlson; Vlad Yasevich
> Subject: RE: address selection and DHCPv6
>
> --> The question is not to get a
Thursday, October 26, 2006 12:37 PM
> To: James Carlson; Vlad Yasevich
> Cc: Durand, Alain; ipv6@ietf.org
> Subject: RE: address selection and DHCPv6
>
> Whatever technique you use will likely never guarantee a
> completely stable address.
>
> Manually assigned is just a
> -Original Message-
> From: Vlad Yasevich [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 26, 2006 9:58 AM
> To: Julien Laganier
> Cc: ipv6@ietf.org; Durand, Alain
> Subject: Re: address selection and DHCPv6
>
>> The concept that a DHCP address is mo
> -Original Message-
> From: Vlad Yasevich [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 25, 2006 10:07 AM
> To: James Carlson
> Cc: ipv6@ietf.org
> Subject: Re: address selection and DHCPv6
> Why do you want to distinguish between DHCP, manual, and
> autoconfigured addresses?
- Alain.
> -Original Message-
> From: Lawrence Zou [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 24, 2006 11:41 PM
> To: Durand, Alain; 'James Carlson'; ipv6@ietf.org
> Subject: RE: address selection and DHCPv6
>
> another rule 9?
>
>
>
&
Lawrence,
You have a point...
For this to work, we may have to do it after the longest prefix match
rule,
but limit the match to the upper 64 bits.
- Alain.
> -Original Message-
> From: Lawrence Zou [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 24, 2006 10:02 PM
> To: 'James Car
I like your rule7bis algorithm.
When RFC3484 was discussed, it was clear that it will need to be
revisited
over time to cover new types of addresses or new use cases.
- Alain.
> -Original Message-
> From: James Carlson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 24, 2006 3:52
> Thanks for the quick e-mail. As one of the co-authors, I'd in
> turn like to reply (and state that ICMPv6 PD is ANOTHER way
> to do IPv6 PD, NOT a replacement for the existing mechanism).
> FWIW, please see comments in-line:
This is probably the crux of the issue. I believe that having
mult
"Currently proposed solution for IPv6 Prefix Delegation is based on
DHCPv6 protocol. We believe that in certain network topologies and
configurations where the CPE routers may not be capable or configured
to use DHCPv6 and hence can not utilize the currently proposed ipv6
prefix dele
In my previous live, we were all using a large server for many things.
That server had 17 physical interfaces. Each interface had one IPv4
address
and 2 IPv6 addressses. Each client had also one IPv4 address and two
IPv6 addresses.
That makes the total combination: 17*2*2 for IPv6 plus 17*1*1 for
> -Original Message-
> From: Bob Hinden [mailto:[EMAIL PROTECTED]
> I made the assumption that from the clients point of view,
> DHCPv6 and DHCPv6-lite are equivalent and didn't call out
> DHCPv6-lite separately in the O flag description. Please
> correct me if I am wrong about this.
> -Original Message-
> From: Thomas Narten [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 18, 2006 9:34 AM
> To: Durand, Alain
> Cc: Ralph Droms; Erik Nordmark; IPv6 Mailing List
> Subject: Re: Proposed M&O bits text for RFC2461bis
>
> "Durand,
-Original Message-
>From: Ralph Droms [mailto:[EMAIL PROTECTED]
>Sent: Mon 4/17/2006 11:18 PM
>To: Erik Nordmark; Thomas Narten
>Cc: IPv6 Mailing List
>Subject: Re: Proposed M&O bits text for RFC2461bis
>
>On 4/17/06 5:51 PM, "Erik Nordmark" <[EMAIL PROTECTED]> wrote:
>
>> Thomas Narten w
10:19 AM
> To: Thomas Narten
> Cc: Durand, Alain; IPv6 Mailing List; Bob Hinden
> Subject: Re: Proposed M&O bits text for RFC2461bis
>
> Thomas Narten wrote:
>
> > Per my comment above, if you don't invoke DHC, you won't
> get all the
> > addr
> -Original Message-
> From: Ralph Droms [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 22, 2006 12:28 AM
> To: Christian Huitema; Fred Baker; Thomas Narten
> Cc: Durand, Alain; IPv6 Mailing List; Bob Hinden
> Subject: Re: Proposed M&O bits text for RFC2461b
> -Original Message-
> From: Christian Huitema [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 22, 2006 12:22 AM
> To: Fred Baker; Thomas Narten
> Cc: Durand, Alain; Bob Hinden; IPv6 Mailing List
> Subject: RE: Proposed M&O bits text for RFC2461bis
>
>&
> -Original Message-
> From: Thomas Narten [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 21, 2006 7:48 PM
> To: Durand, Alain
> Cc: Bob Hinden; IPv6 Mailing List
> Subject: Re: Proposed M&O bits text for RFC2461bis
>
> No, it means that if you don&#
> M :
> 1-bit "Managed address configuration" flag. When set, it
indicates
> that addresses are available via Dynamic Host Configuration
Protocol
> [DHCPv6], including addresses that were not configured via
stateless
> address autoconfiguration.
I'm not sur
>>> that uses IEEE EUI-48 and MAC-48 identifiers on the same link,
>>> the
>>> 0xFF and 0xFF values could be used to convert the EUI-48
>>> identifiers
>>> for use as IPv6 interface identifiers to avoid any potential for
>>> duplicate interface identifiers.
>>
>> I said 'personall
>
> Issue 3: Discovery of tunnel endpoints.
>
> Resolution:
> This change will be made and will be based on the text proposed
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html
I'm not sure this is such a good idea.
A) there are may kinds of tunnels, like IPv6/UDP/I
Geoff,
The question is: can those identifier leak from an application and then be used
as locators?
If there is a risk of leak, there is a need for a separate prefix. If we are
100% sure there is no way that any application would ever leak, then I would
agree we do not need to use a dedicated
The follow up question is:
Have host generally implemented the check of the A bit in RA and has this been
tested at UNH/TAHI/ETSI/...
- Alain.
-Original Message-
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: ipv6@ietf.org
Sent: Mon Oct 31 14:17:17 2005
Subject: Question about p
I will disagree restricting the usage of this protocol to Link Local only. This
is an helpful
tool when managing networks.
Adding a warning statement in the security section to recommend filtering out
this particular
ICMP message at site boundary should be enough.
- Alain.
_
As a follow-up to
the TC bof in Minneapolis and the LRW bof in Paris, we have set-up a mailing
list:
[EMAIL PROTECTED]
Hopefully the name
will not change, (but we never know... ) once the wg will be ceated by
IESG.
To subscribe,
visit:
https://www1.ietf.org/mailman/listinfo/softwires
Pr
35 matches
Mail list logo
