Brian Dickson wrote:
[..]
> If an ISP gets a /32, and gives out /48's, which they can do without
> requiring supporting documentation,
> and reserves space for each allocation (say a nibble), that leaves only
> 12 bits of "range", or 4096 customers.
You do realize that a /48 is *65536* /64's and a
> I'm not arguing for changing *all* of IPv6 away from EUI-64.
>
> I'm arguing *for* *allowing* choices of II format of EUI-64 *or* any
> other suitable unique II specific to the layer 2 medium.
making the host ("interface ID" in IPv6-speack) to be fixed length,
with bigger bitwi
Brian E Carpenter wrote:
We're arguing past each other.
I am never going to agree that we have a shortage of bits
in ::/64. If we waste those bits due to inserting an
unnecessary hierarchy in the prefix assignment process,
shame on us. If the current registry practices are having that
effect, th
> > Choosing EUI-64 format was a strategic decision taken from
> > a very long term (many decades) viewpoint. I see no case
> > for changing that choice.
>
> My personal view as well.
Doing something like SEND would require much more work if there were less than
64 bit in the host ID.
-- Christi
On Sep 19, 2007, at 3:07 PM, ext Brian E Carpenter wrote:
We're arguing past each other.
I am never going to agree that we have a shortage of bits
in ::/64. If we waste those bits due to inserting an
unnecessary hierarchy in the prefix assignment process,
shame on us. If the current registry p
We're arguing past each other.
I am never going to agree that we have a shortage of bits
in ::/64. If we waste those bits due to inserting an
unnecessary hierarchy in the prefix assignment process,
shame on us. If the current registry practices are having that
effect, then we need to work with th
I and I suspect others took it as a serious question. Since you
didn't answer, I ignored your poll.
I didn't answer *yet* as of then, but have answered it now.
Does this mean you'll answer the poll now?
Sure, 100% auto-config.
Bob
-
Bob Hinden wrote:
On Sep 19, 2007, at 1:40 PM, ext Brian Dickson wrote:
Bob Hinden wrote:
Yes, right after you sent the poll. See:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg08529.html
I thought it was odd you didn't respond.
Okay, I stand corrected. I got *one* request for
On Sep 19, 2007, at 1:40 PM, ext Brian Dickson wrote:
Bob Hinden wrote:
Yes, right after you sent the poll. See:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg08529.html
I thought it was odd you didn't respond.
Okay, I stand corrected. I got *one* request for a clarification,
Bob Hinden wrote:
Yes, right after you sent the poll. See:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg08529.html
I thought it was odd you didn't respond.
Okay, I stand corrected. I got *one* request for a clarification, and it
was from Illjitsch.
Because of who asked the questi
Brian,
I think the reason for the small number of responses was that you
never clarified if you were talking about hosts, routers, or both.
Hmmm
I never received any requests for clarification, so I don't agree
that it was confusing.
Do you know of anyone personally that chose not to an
Bob Hinden wrote:
On Sep 13, 2007, at 12:58 PM, ext Brian Dickson wrote:
[EMAIL PROTECTED] wrote:
(I realize this list might not represent the bulk of the deployed IPv6
networks... nonetheless, I'm curious.)
This is an informal survey of what is deployed in terms of IPv6
networks.
Do you u
On Sep 13, 2007, at 12:58 PM, ext Brian Dickson wrote:
[EMAIL PROTECTED] wrote:
(I realize this list might not represent the bulk of the deployed
IPv6
networks... nonetheless, I'm curious.)
This is an informal survey of what is deployed in terms of IPv6
networks.
Do you use autoconf only
> > > This still breaks the notion that once you do duplicate address
> > > detection for your MAC-derived link-local address you can assume that
> > > any other MAC-derived addresses are also unique.
>
> no.
i was too vague. dig up the archive and see the never-ending
di
> > This still breaks the notion that once you do duplicate address
> > detection for your MAC-derived link-local address you can assume that
> > any other MAC-derived addresses are also unique.
no.
itojun
IETF IPv6 w
> > From a purely cosmetic standpoint, I think MRU (Max Receive Unit) is a lot
> > more readable that EMTU_R.
>
> I agree about the cosmetics, however "EMTU_R" is precisely
> defined in RFC1122 and is used in this document exactly
> per its RFC1122 specification. I couldn't find a similar
> refer
Iljitsch van Beijnum wrote:
This still breaks the notion that once you do duplicate address
detection for your MAC-derived link-local address you can assume that
any other MAC-derived addresses are also unique.
How does it break this notion?
Consider:
RFC 2462 says if DAD fails for link-local,
Hi Remi,
> -Original Message-
> From: Rémi Denis-Courmont [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 19, 2007 7:31 AM
> To: ipv6@ietf.org
> Cc: Templin, Fred L; Brian E Carpenter
> Subject: Re: [Fwd: Re: [RRG] Re: [RAM] Tunneling overheads
> and fragmentation]
>
> Le Tuesda
Le Tuesday 18 September 2007 23:43:30 Templin, Fred L, vous avez écrit :
> Brian,
>
> After having discussed with others, please see attached
> for a proposal that addresses the MTU issues for tunnels.
> It also addresses the multi-mtu subnet issue, since it
> does not rely on ICMP "packet too big"
> According to RFC 3627 /128 is not a good idea. It should be /126.
RFC3627 doesn't say that. It says: "Using two /128
addresses is also one, though often cumbersome,
approach.", but it doesn't say that using /128 is
not a good idea.
Fred
[EMAIL PROTECTED]
---
On 19-sep-2007, at 15:56, Brian Dickson wrote:
Iljitsch van Beijnum wrote:
I haven't read all your messages on the subject yet, but how do
you handle the universal/local bit that's in the 16 bits that you
want to reclaim?
The U/L bit is currently being munged on the high bit of the
EUI
Iljitsch van Beijnum wrote:
I haven't read all your messages on the subject yet, but how do you
handle the universal/local bit that's in the 16 bits that you want to
reclaim?
The U/L bit is currently being munged on the high bit of the EUI-64,
which is the high bit of the OUI part of the MAC-
On 19-sep-2007, at 2:52, Brian Dickson wrote:
The problem is, that we don't *have* those 16 bits to reclaim,
ever, since we give them away with *every* allocation from space
that is assigned to us.
Your assumption is that the best place to keep those bits is at the
ISP/LIR, RIR or IANA. I
> The loopback /128 is a special case exception because a
> loopback doesn't ever have more than one node on the "link",
> nor will there be a router, so fixed and reserved /128 value
> is a good solution.
According to RFC 3627 /128 is not a good idea. It should be /126.
--Michael Dillon
---
24 matches
Mail list logo
