>> Irina Dayal wrote:
> 1) Is it safe to assume that all IPv6 prefixes will be between
>> 16 and 64 bits long?
> Keith Moore wrote:
> no. because nothing requires a site to use the lower 64 bits
> as an interface ID - a site is free to subnet that space if
> it wishes.
I have to disagree with K
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 : Recommendations for IPv6 in 3GPP Standards
Author(s) : M. Wasserman
Filename
Hi folks,
Someone seems to have decided to re-send hundreds of old messages to
your lists tonight. Fortunately, I was on duty and noticed a general
problem, and one of your list mates (George Mitchell) was diligently
paying attention and provided me with helpful details which greatly sped
up my
kre,
>> Michel Py wrote:
>> Absolutely. If you dial into your company, there is nothing that I
>> know of that says you must get a /64. The allocation of the SLA
>> bits is at the discretion of the company's network administrator,
>> and allocating a /60 to ...
> kre wrote:
> A while ago, you we
I just went into my inbox and had to download 114 ipng messages (and
only ipng messages) of various dates...
has anybody else noticed this? I mean that is a rediculous amount of
messages to go through. I wasn't thrilled. If I were on 56k i really
wouldn't be happy having to hang my connection u
Date:Wed, 13 Feb 2002 08:51:23 -0800
From:"Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| Absolutely. If you dial into your company, there is nothing that I
| know of that says you must get a /64. The allocation of the SLA
| bits is at the dis
"PD (Automatic Prefix Delegation)" is one of the choices.
draft-haberman-ipngwg-auto-prefix-01.txt
http://search.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-01.
txt
To solve all the configuration issues with DHCPv6 might be another good
choice, but I guess PD be a minimum requirem
> I have to disagree with Keith here. If a site wants to subnet,
> they get a /48 and use the 16 SLA bits to subnet, that is what
> they have been designed for.
depends on what you mean by 'site', I suppose. Even if RFC 3177 is
followed, I would not want the network to presume that a /64 net
(s
We recently received notice that the 3GPP has approved a change request
to their GPRS architecture specification (23.060) based on the IPv6 WGs
recommendations in draft-ietf-ipv6-3gpp-recommend-00.txt.
The 3GPP has modified their address allocation mechanism to assign a
prefix per primary PDP c
This is a IPv6 working group last call for comments on advancing the
following document as an Informational RFC:
Title : Advanced Sockets API for IPv6
Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei
Filename: draft-ietf-ipngwg-rfc2292bis-
> Irina Dayal wrote:
> 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64
> bits long? The current allocation of IPv6 prefixes seems to require
> Aggregatable Global Unicast Addresses, which restricts the prefixes to
> this range.
It's not safe (even if it might be true tod
I am new here so please excuse the trivial questions. I did trawl the archives but
could not find a definitive answer.
1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits long?
The current allocation of IPv6 prefixes seems to require Aggregatable Global Unicast
Addre
In your previous mail you wrote:
1) Is it safe to assume that all IPv6 prefixes will be between 16
and 64 bits long? The current allocation of IPv6 prefixes seems to
require Aggregatable Global Unicast Addresses, which restricts the
prefixes to this range.
=> if this seems to be sa
> 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits
> long?
no. because nothing requires a site to use the lower 64 bits as an
interface ID - a site is free to subnet that space if it wishes.
IETF I
> On Wed, 13 Feb 2002 12:11:40 -0800 (PST),
> Tim Hartrick <[EMAIL PROTECTED]> said:
> I have never and still don't see the need to disambiguate between destination
> options which come before the routing header and those that come after. On
> the send side it is easy to order your anci
> In your previous mail you wrote:
>
>I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks
>about the negotiation of the Interface-Identifier and specifies the
>Interface-Identifier Configuration Option. In this case the upper 64 bits
>are just fe80::
>
> =
In your previous mail you wrote:
Since PPP does not support multicast,
=> I disagree:
x% uname -sr
FreeBSD 4.5-RELEASE
x% ifconfig ppp0
ppp0: flags=8010 mtu 1500
^
Is this what most implementations do?
=> they implement multicast (all of them, I
In your previous mail you wrote:
I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks
about the negotiation of the Interface-Identifier and specifies the
Interface-Identifier Configuration Option. In this case the upper 64 bits
are just fe80::
=> yes, IPv6CP p
Since PPP does not support multicast, this will involve a smart NDP that
takes into consideration the type of interface as well i.e. we cannot send
a router solicitation to the all-routers address/send a router
advertisement to all-nodes and so on.
Is this what most implementations do? I would l
At 03:28 PM 2/13/2002 -0600, Lilian Fernandes wrote:
>Hi,
>
>I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks
>about the negotiation of the Interface-Identifier and specifies the
>Interface-Identifier Configuration Option. In this case the upper 64 bits
>are just fe80::
>
Hi,
I have a question about RFC2472 - "IP Version 6 over PPP". The RFC talks
about the negotiation of the Interface-Identifier and specifies the
Interface-Identifier Configuration Option. In this case the upper 64 bits
are just fe80::
It does not mention if there is any standard way to configur
Tim
The IPV6_RTHDRDSTOPTS is a send side only option any more (at least thats
how the spec reads). For the recieve side, IPV6_DSTOPTS gets you all
the destination options.
I guess that might be considered another argument for removing this option...
On the other hand, ordering of setsockopt()
All,
> >
> > >Please let me make sure about this comment...are you proposing to
> > >remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper
> > >position of a destination options header (only with the IPV6_DSTOPTS
> > >option)?
> >
> > > => yes
> >
> > >If so, h
In your previous mail you wrote:
> I think the philosophical question is deeper.
> Knowing the size of IP packets that can be sent without IP fragmentation
>...
(As a "philosophical" argument) I agree with all the points. But as
for the API document, we should (or can) just k
In your previous mail you wrote:
>Please let me make sure about this comment...are you proposing to
>remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper
>position of a destination options header (only with the IPV6_DSTOPTS
>option)?
> => yes
>
JINMEI Tatuya wrote:
>
> >Please let me make sure about this comment...are you proposing to
> >remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper
> >position of a destination options header (only with the IPV6_DSTOPTS
> >option)?
>
> > => yes
>
> >If so, how can
In your previous mail you wrote:
> > - 11.4: there is a discussion about MTUs and extra headers added by
> >the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should
> >not take into account the headers. But this makes it less useful
> >for the programmer...
> On Wed, 13 Feb 2002 14:56:52 +0100 (CET),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> > - 11.4: there is a discussion about MTUs and extra headers added by
(snip)
>> So, I'd propose to clarify that the MTU is an "IP MTU" (in your
>> definition above) and can be larger than the actu
> On Tue, 12 Feb 2002 20:16:10 +0100,
> Francis Dupont <[EMAIL PROTECTED]> said:
>> - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing
>One of the main decisions in recent revisions of this draft is...
> => so we have to require the definitions somewhere (a rfc2292ter I-D?)
Pekka, Dale, kre, others,
I consolidated several postings into one
>>> 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.
>> Michel
> > - 11.4: there is a discussion about MTUs and extra headers added by
> >the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should
> >not take into account the headers. But this makes it less useful
> >for the programmer... (note: this is just a philosophical question
>
This has been going on for quite and while. And I keep asking myself --
Why not /60 for dialups?
Its on a nice nibble and gives a good handfull of subnets for the SOHO.
Dale Sesvold
Senior Engineer
MacAulay-Brown, Inc
-Original Message-
From: Dan Lanciani [mailto:[EMAIL PROTECTED]]
Se
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 : Advanced Sockets API for IPv6
Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei
In your previous mail you wrote:
T= 0.5 seems fairly high. Why not .1 or .01 (on today's links).
=> I agree because T should be in milliseconds (f.1) and
is against back-to-back erroneous packets. I propose 20ms (50Hz).
So, question for the WG: Is the current text on this topic adequa
Date:Tue, 12 Feb 2002 16:15:40 -0800
From:"Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| A dial-up connection gets a /48.
Always?
Really?
Sure, if you're dialing into an ISP, with a whole bunch of /48's to
issue (as static assignments, or
Date:Tue, 12 Feb 2002 21:33:07 -0500
From:Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Would it be better to move away completely from fixed time intervals
| and just say as a percentage of the link traffic? at least in the case
| of route
On Tue, 12 Feb 2002, Thomas Narten wrote:
> 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 second, NOT 0 secon
On Sun, 10 Feb 2002, Michel Py wrote:
> > What do others think -- is this something worth noting?
>
> Overall, I find the text excellent.
>
> I oppose solutions 2,3 and 4 because they bring extra
> complexity to solve a problem that does not exist. The problem
> that does not exist is the need t
38 matches
Mail list logo
