That is why I think a /48 only upon customer or equipment request, and a
smaller number by default is the best overall way to go.
"Upon Request" also includes devices that do dhcp prefix delegation as
well. It would be helpful if the makers of these devices would not
default to always
On 05/01/2020 15:26, hostmas...@uneedus.com wrote:
It is also likely that the policy of many large ISP's to give a /60 or
/56 by default instead of a /48 may not be motivated by any attempt at
address conservation, but simply to prevent the ISP from having to ask
for more v6 space from
I slipped up on the calculation. I assumed 2000::/3 was 2000:: to
2fff:::::::. It actually extends to
3fff:::::::. Guess I slipped up on the hex
math. My mind always thought the 6 bone addresses were in the next block,
but of course now
Spot on. Excellent analysis and great job breaking down the facts.
On Mon, Jan 6, 2020 at 06:46 Owen DeLong wrote:
>
>
> > On Jan 4, 2020, at 12:41 , hostmas...@uneedus.com wrote:
> >
> > I understand that there might have been some poor choices made with IPv6
> in regard to address allocation
> On Jan 4, 2020, at 12:41 , hostmas...@uneedus.com wrote:
>
> I understand that there might have been some poor choices made with IPv6 in
> regard to address allocation that might lead to a future exhaust. The main
> one is the 64 bit network and 64 bit host decision, considering that it
I did not write this to open a debate on IPv6 exhaustion, but merely to
point out that policies could be changed in the future to reduce address
consumption within IPv6 if the community found it is needed.
Looking at the IANA assignments of the first 1/16 of the address space, it
is highly
On Sat, Jan 4, 2020 at 20:15 David Farmer wrote:
>
>
> On Sat, Jan 4, 2020 at 17:27 Ronald F. Guilmette
> wrote:
>
>> In message <
>> camdxq5mbe2dn9awxho-h-p8g3yqwbaak-rxr7uqmtac5pbt...@mail.gmail.com>
>> Martin Hannigan wrote:
>>
>> >Talking about v6 exhaustion is probably better suited for
On Sat, Jan 4, 2020 at 17:27 Ronald F. Guilmette
wrote:
> In message <
> camdxq5mbe2dn9awxho-h-p8g3yqwbaak-rxr7uqmtac5pbt...@mail.gmail.com>
> Martin Hannigan wrote:
>
> >Talking about v6 exhaustion is probably better suited for the IETF. Either
> >way, we'll all be dead if/when it happens...
>
In message
Martin Hannigan wrote:
>This all seems silly to me. #IMHO, IPv4 policy should be geared only mostly
>assuaging operators to get to v6. Total exhaustion is a part of that.
If that's a goal, total IPv4 exhaustion could be legislated -today-. All
five RIRs would simply have to agree
This all seems silly to me. #IMHO, IPv4 policy should be geared only mostly
assuaging operators to get to v6. Total exhaustion is a part of that.
Talking about v6 exhaustion is probably better suited for the IETF. Either
way, we’ll all be dead if/when it happens and it is not unreasonable to
avoid
I understand that there might have been some poor choices made with IPv6
in regard to address allocation that might lead to a future exhaust. The
main one is the 64 bit network and 64 bit host decision, considering that
it was based on 48 bit ethernet OUI's. I think it should have been 80 bits
In message ,
hostmas...@uneedus.com wrote:
>[IPv6] also brings RIR's
>back to their original record keeping role, without having to police the
>number of addresses that a member needs.
I am not persuaded that this will be the case. When IPv4 was first
promulgated, I do believe that just
The right answer is a return to an enviroment where there is no address
shortage. Of course that spells IPv6.
Getting back to the the simple record keeping role is already there in
IPv6 when there is no shortage of addresseses. The only issue is getting
to a tipping point where v6 is used
On Fri, Jan 3, 2020 at 3:44 PM Ronald F. Guilmette
wrote:
> To be frank however, I'm not fully persuaded that the term "landlord"
> should be so cavalierly tossed around as an epithet with distinctly
> negative connotations. [...] I don't know the right answer,
Taxes. That's how it works in
In message <007801d5c283$ab54e6b0$01feb410$@iptrading.com>,
"Mike Burns" wrote:
>You are forgetting that anybody can do this in RIPE today.
>And yesterday.
You say that as if it is strictly a theoretical possibility.
Regards,
rfg
___
ARIN-PPML
In message ,
hostmas...@uneedus.com wrote:
>There are those that wanted to become landlords of IPv4. I think this
>kinda shoots down those hopes.
It would appear so.
To be frank however, I'm not fully persuaded that the term "landlord"
should be so cavalierly tossed around as an epithet with
--Original Message-
> From: ARIN-PPML On Behalf Of
> hostmas...@uneedus.com
> Sent: Friday, January 03, 2020 4:59 PM
> To: Fernando Frediani
> Cc: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Fwd: Advisory Council Meeting Results - December
> 2019
>
> There ar
-ppml@arin.net
Subject: Re: [arin-ppml] Fwd: Advisory Council Meeting Results - December 2019
There are those that wanted to become landlords of IPv4. I think this kinda
shoots down those hopes.
Albert
On Fri, 3 Jan 2020, Fernando Frediani wrote:
> What a great thing to read about ARIN-2
There are those that wanted to become landlords of IPv4. I think this
kinda shoots down those hopes.
Albert
On Fri, 3 Jan 2020, Fernando Frediani wrote:
What a great thing to read about ARIN-2019-18 and a good message to
'lessors-to-be' or 'number resource landlords'. Well done AC.
On
What a great thing to read about ARIN-2019-18 and a good message to
'lessors-to-be' or 'number resource landlords'. Well done AC.
On 03/01/2020 18:42, ARIN wrote:
The minutes from the ARIN Advisory Council's 19 December 2019 meeting
have been published:
The minutes from the ARIN Advisory Council's 19 December 2019 meeting
have been published:
https://www.arin.net/about/welcome/ac/meetings/2019_1219/
Regarding Draft Policy ARIN-2019-18, the AC has released the following
statement:
"At its monthly meeting on December 19 2019, the ARIN AC
21 matches
Mail list logo
