Laurent - assuming you want aggregation for routing, the ISP DHCPv6 server
would have to be configured to recognize that A and B are downstream from
the CPE, and therefor should be assigned /64s that somehow aggregate under
the /48 assigned to the CPE.
Pushing the responsibility to a DHCPv6 server
Mukesh,
I briefly looked through your draft and I agree with Gab's assessment. The
types outlined there for "private experimental" use are not appropriate for
the Seamoby and FMIP protocols because we don't expect there to be multiple,
concurrent usage of these types. We expect there to be co-ordi
Hi,
The next IETF is fast approaching. Please forward any proposed
agenda items for IPv6 to Bob and me.
Regards,
Brian & Bob
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.o
[EMAIL PROTECTED] wrote:
Please look at section 2.1 (Message General Format). The section
adds type 100, 101, 200 and 201 for private experimentation. Also
section 6 (IANA consideration) describes a policy on allocating
reclaimable ICMP type and code values.
Hi,
Not sure we can use 100,101,200 o
Thank you Tony and Christian for your answers.
In my question, I missed the point that the ISP and CPE are in different
domain,
so the distribution of the /48 to the CPE is supposed to follow a
different policy
than how the /64 are distributed.
And having 2 levels of DHCPv6 PD servers is scalable
Christian Huitema wrote:
It makes sense, but there is one pitfall. More and more, firewalls come
with restrictive rules about what ICMP packets will be allowed. These
rules typically operate on ICMP type and ICMP code. Having a single
type-code combination for all experimental packets will force an
I've not seen direct comments on the proposed text (I've seen a
side discussion regarding this topic, so I know at least a few people
have been aware of the proposal).
I've already edited my local copy of rfc2462bis based on the proposal,
which will soon be submitted (probably within a week). It
Gabriel,
I have submitted the updated version of the ICMPv6 draft
(draft-ietf-ipngwg-icmp-v3-04.txt) today. The draft is available at
http://sonic.net/~mukesh77/draft-ietf-ipngwg-icmp-v3-04.txt till it
appears on the IETF website.
Please look at section 2.1 (Message General Format). The secti
> On Tue, 01 Jun 2004 08:24:13 +0200,
> "Christian Strauf (JOIN)" <[EMAIL PROTECTED]> said:
>> I find the language somewhat confusing. This is what I undestand the paragraph
>> to say:
> [...]
> Yes, this is what the paragraph means and I agree with Jinmei that we
> should include this
The proposed resolution seems to have achieved consensus.
I'll close this issue and revise the text as proposed.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/list
The proposed resolution seems to have achieved consensus.
I'll close this issue and revise the text as proposed.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/list
> On Tue, 01 Jun 2004 08:36:42 +0200,
> "Christian Strauf (JOIN)" <[EMAIL PROTECTED]> said:
>> 1. the original proposed text of mine
>> 2. the new proposed text of mine
>> 3. the text you proposed
> I can live with 1.) for the moment because I agree that it's not within
> the scope of rfc
On 2004-06-02, Pekka Savola wrote:
>
> My concern with using the unspecified address comes from the
> experience we had in MAGMA where we had to specify which source
> address to use in the MLDv1 packets [...]
This is another one of those situations where I'm not trying
to improve 2461/2 behaviou
13 matches
Mail list logo
