On Fri, 26 May 2017, Ronald F. Guilmette wrote:
In message ,
hostmas...@uneedus.com wrote:
Only the largest IPv4 customers are subject to SWIP, not the majority of
the total customer base.
Just when I though that I was beginning to understand, now I am *really*
confused. You say "Only the
Hello,
I'd like to register another vote in support of relaxing IPv6 SWIP requirements
in 6.5.5.1 to /60, but eliminating the 4.2.3.7.1 IPv4 changes from this
proposal.
Regards,
Ken Mix
-Original Message-
From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of ARIN
Sent: Tues
In message ,
hostmas...@uneedus.com wrote:
>Only the largest IPv4 customers are subject to SWIP, not the majority of
>the total customer base.
Just when I though that I was beginning to understand, now I am *really*
confused. You say "Only the largest IPv4 customers are subject to SWIP",
but
On May 26, 2017, at 9:35 PM, "hostmas...@uneedus.com"
wrote:
> ...
> Enforcement I think should be left to another proposal, and do not think that
> I am the one that will be drafting such a proposal, and do not think the
> enforcement issues are helpful in trying to decide where the boundary s
On Sat, 27 May 2017, Peter Thimmesch wrote:
Albert,
I concur 100% with your goal here and believe that there is a path to
creating an equitable policy. Therefore I support, and ask others
responding to this thread, with the intent of your policy proposal.
The sole question, outside of "size
Peter,
I agree that this policy should be about the sizing of SWIP assignments in IPv6
only.
I would prefer that any issue related to enforcement be left out of the policy
(I don't see it in the current draft).
The benefit of having an appropriate size, is that it shows the community what
th
Albert,
First, I wanted to say that both as a member of the community (as a
network operator) and as an AC member, I was exceedingly happy when you
proposed this draft policy. I don't agree with everything you have
written, but I agree with a lot of it, and I think the draft policy
language
Albert,
I concur 100% with your goal here and believe that there is a path to creating
an equitable policy. Therefore I support, and ask others responding to this
thread, with the intent of your policy proposal.
The sole question, outside of "size" of the v6 cut-off, is whether there should
b
So, let me see if I understand this...
ARIN doesn't, can't, and most probably won't either enforce the existing
(IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be
drafted and/or promulgated with respect to IPv6. Is that about the size
of it?
If so, then color me perplexed.
In message ,
hostmas...@uneedus.com wrote:
>In the case of v4, often the records were only put in place right before
>attempting to get another allocation...
Yes. I myself can still remember, back in the day... before the law
changed in my state... throwing the roach out the car window, just
Hello Cathy,
Yes, the was some rather heated discussion at the ARIN meeting in New Orleans
about the proposed wording in 3.6.7 Non-Responsive Point of Contact Records. I
believe, please correct me if you think otherwise, that the consensus of
opinions that spoke at the meeting were strongly aga
In message
Scott Leibrand wrote:
>> So, let me see if I understand this...
>>
>> ARIN doesn't, can't, and most probably won't either enforce the existing
>> (IPv4) SWIP rules, nor, for that matter, any new SWIP rules that may be
>> drafted and/or promulgated with respect to IPv6. Is that about
When either these new SWIP rules, for IPv6, or the current SWIP rules,
for IPv4 are violated... as they appear to be, with great frequency,
from where I am sitting... then who does one call? The Internet Police?
The only real "Police" is when ARIN uses the SWIP data to justify another
allocat
Scott,
On Fri, May 26, 2017 at 4:45 PM, Scott Leibrand
wrote:
> On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette <
> r...@tristatelogic.com> wrote:
>
>>
>> In message <8a3a301d-39b5-4f81-8e2c-90e23b819...@panix.com>,
>> David Huberman wrote:
>>
>> >In short, there is an argument that the SW
On Fri, May 26, 2017 at 3:32 PM, Ronald F. Guilmette
wrote:
>
> In message <8a3a301d-39b5-4f81-8e2c-90e23b819...@panix.com>,
> David Huberman wrote:
>
> >In short, there is an argument that the SWIP rules are no-op now. So to
> answer
> >your question directly; what do you do? Nothing. Those day
In message <8a3a301d-39b5-4f81-8e2c-90e23b819...@panix.com>,
David Huberman wrote:
>In short, there is an argument that the SWIP rules are no-op now. So to answer
>your question directly; what do you do? Nothing. Those days are long gone
>and ARIN has other focuses now.
So, let me see if I und
rfg,
The mandatory SWIP requirements are an anachronism from a time where they were
moderately enforceable. For many many years, a traditional, vanilla-flavored
ISP would get a block from ARIN, allocate a lot of it to dynamic pools. SWIP
out the static /29 and larger assignments to customers,
In message ,
hostmas...@uneedus.com wrote:
>What I would like to hear from the community is their input as to where to
>draw the line for 6.5.5.1...
What you would like, and what I would like appear to be two dramatically
distinct things.
I would like to just also offer the observation that I
pardon top-post; on mobile
the spec doesn't match operational reality, hence
https://datatracker.ietf.org/doc/draft-bourbaki-6man-classless-ipv6/
cheers,
Joe
On Fri, May 26, 2017 at 12:22:37AM -0400, hostmas...@uneedus.com wrote:
> RFC 4291, section 2.5.4 provide that the interface ID is /64 f
This proposal was intended to try to bring the v4 and v6 world together on
the same policy. Because of the nibble boundary rule and rDNS, on the v6
side, there are really only 5 choices in network size: /48, /52, /56, /60
and /64 without having to do non-standard CNAME tricks used when
subdivi
RFC 4291, section 2.5.4 provide that the interface ID is /64 for all
global unicast addresses, which is the reason that all v6 lan networks are
set to /64, and this should include p2p links
Network World at the time had quite a discussion about this and RFC 6164.
They point out that we have no
21 matches
Mail list logo