On Tue, 12 Feb 2002, Michel Py wrote:
> > Dan Lanciani wrote:
> > An obvious reason would be that the one who wishes to subnet
> > the /64 is not the same one who should have used a /48, with
> > the former one having little control over the latter one.
>
> A dial-up connection gets a /48.
N
In reviewing this ID prior to approving the IETF Last Call, I have the
following questions/comments:
> Rate limiting:
>
> The limit parameters (e.g., T or F in the above examples) MUST
> be configurable for the node, with a conservative default value
> (e.g., T = 0.5 seco
> Dan Lanciani wrote:
> An obvious reason would be that the one who wishes to subnet
> the /64 is not the same one who should have used a /48, with
> the former one having little control over the latter one.
A dial-up connection gets a /48.
"Michel Py" <[EMAIL PROTECTED]> wrote:
[much snipped]
|and I still fail to see a valid reason to subnet
|a /64 when one should have used a /48 and subnet using the SLA
|bits.
An obvious reason would be that the one who wishes to subnet the /64
is not the same one who should have used a /48, wit
> Allocations on non-nibble boundaries are possible of course.. it could
> just mean about 8 different almost identical delegations in the worst
> case.
Right. Which should trivially easy to automate for any organization
big enough to need to worry about it.
> Or are you referring to "Class-les
In your previous mail you wrote:
Why do you belive the IPV6_RTHDRDSTOPTS is unnecessary?
Is it because of the lack of options that would go into this header?
=> this is the main reason. In fact the only destination option
in the draft (or in a RFC), the tunnel encapsulation limit,
needs t
Francis
Francis Dupont wrote:
>
>If so, how can a user specify a couple of destination
>options headers before and after a routing header?
>
> => he cannot but he doesn't need it and he cannot specify
> a destination option header just before a fragmentation header.
> IPV6_RTHDRDSTOPTS
In your previous mail you wrote:
> Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt:
Thanks for the detailed comments. (But, yeah, this is a bit late. I
just submitted the 05 version...)
=> sorry...
> - 0: is it time to alias sin6_scope_id to sin6_zone_id (far
> On Tue, 12 Feb 2002 14:15:14 +0100,
> Francis Dupont <[EMAIL PROTECTED]> said:
> Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt:
Thanks for the detailed comments. (But, yeah, this is a bit late. I
just submitted the 05 version...)
> - 0: is it time to alias sin6_scop
Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt:
- 0: is it time to alias sin6_scope_id to sin6_zone_id (far better name
but not suitable for the basic API)?
- 2.1.1: IPPROTO_IPCOMP (108, RFC 3173) is missing (as usual :-).
- 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing
Erik Nordmark <[EMAIL PROTECTED]> writes:
> > First, I find CGA (Computationally Generated Addresses) mechanisms to
> > have valuable IP security properties and are probably exploitable in
> > some contexts.
>
> CGA = Cryptographically Generated Addresses
Right.
EGA = Expensively Generated Addr
11 matches
Mail list logo
