Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

[hostmaster]

While these OS's do use the privacy extensions by default for all outbound 
connections, and the addresses are changed every 24 hours or so, from what 
I see, they also listen on the MAC address based address as well, and if 
they accept inbound connections with their firewall, the MAC based address 
can be used inbound as well.


Also, if there is a DHCP6 server, an additional address is also obtained, 
and the system listens on this address.


With IPv6, most systems might have both the old and new privacy address 
configured (the new being the default for outbound) as well as DHCP6 and 
SLAAC based addresses all in use. Most do not release the privacy address 
until there is no longer any outbound connection using it. 
Ifconfig/ipconfig will show this fact, even on the latest OS's


I simply brought it up as a possible counter argument, but in no case 
would I consider any of these addresses to be "Static".


Also, older Android does not use DHCP6 or privacy addresses, leading to 
one of the biggest tracking leaks.


Albert Erdmann
Network Administrator
Paradise On Line Inc.



On Tue, 19 Sep 2017, David Farmer wrote:


I don't know if its a majority of devices yet, but with RFC8064 the use of
IIDs based on MAC addresses are no longer recommended, and stable addresses
are recommended to be generated on based on RFC7217.

https://tools.ietf.org/html/rfc8064
https://tools.ietf.org/html/rfc7217

Now it will take a while for new code to completely permeate the industry,
but I believe the latest updated for Windows, MAC OS, iOS, and Android, all
use this new standard.  I have anecdotal evidence, by playing with my
iPhone that was just upgraded to iOS11 that it support this standard.  I
don't remember if this was a feature added iOS 10.X or not.

I believe it is safe to say the majority of new devices no longer use an
IID based on a MAC address.  Other than the MAC address of the interface is
one of the seeds into the pseudo-random algorithm.

Thanks

On Tue, Sep 19, 2017 at 12:17 PM, Owen DeLong  wrote:



On Sep 19, 2017, at 1:28 PM, Leif Sawyer  wrote:

The majority of devices no longer register on SLAAC with MAC-bound
addresses.


Technically, this isn???t true.

The majority of devices now register both one or more privacy addresses
_AND_ a MAC-bound address. The MAC-bound address on such devices is not
used as a preferred or primary address for originating sessions, but can be
used (if known by the remote device) as a stable address to connect to
services provided by the host.


Privacy Extensions for Stateless Address Autoconfiguration in IPv6???, which
is codified in RFC 4941
means randomly generated addresses on a rotating basis.

You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's
really not.


I think the better consideration is that when we talk of allocation and/or
assignment, we are talking of the allocation/assignment of network numbers
end not of host-portions to end devices. As such, I don???t think that the
blurring Albert perceives as being created by SLAAC truly exists regardless
of whether it is static or not.

Owen


Leif


*From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net
] *On Behalf Of *hostmas...@uneedus.com
*Sent:* Tuesday, September 19, 2017 3:25 AM
*To:* arin-ppml@arin.net
*Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved
IPv6 Registration Requirements

[External Email]

Placing ISP/LIR in place of ISP might be the best way to avoid confusion.
As has been pointed out, they are really one and the same.

Otherwise, I think that everything else about the draft is good and
support.

One thing to consider for future discussion is that because of the nature
of IPv6, and its end-to-end nature, and assignment of public addresses,
that the difference between allocate and assign using IPv6 on a specific
/64 segment used for public wifi or otherwise is becoming more fluid.

With SLAAC, an address is formed in part using a MAC address, which
according to the rules for MAC addresses is supposed to be unique. It
could be argued that these addresses are in effect "static", which could
be argued is an assignment of part of the host network's /64, in effect a
static /128 of that network. Due to the rules of SLAAC this happens
without involvement of the host network, other than router advertisements,

since the MAC originates from the guest device, as a different device will

have a different MAC address.

The requirement of at least a /64 in the proposed 6.5.5.4 is good in that
end user networks that have SLAAC cannot be required to register the /128
associated with someones MAC address on their request. Since this limit
is in the proposal, I think we do not need to address the fact that end
user networks running IPv6 and SLAAC in effect are assigning addresses to
end user devices, even though they are not supposed to do this unless the
addresses were allocated to them like an ISP/LIR. 

Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

[Owen DeLong]

Linux (Fedora 25) and MacOS (Sierra) at least, it’s still using stable 
addresses based on MAC address.

Owen

> On Sep 19, 2017, at 4:28 PM, David Farmer  wrote:
> 
> I don't know if its a majority of devices yet, but with RFC8064 the use of 
> IIDs based on MAC addresses are no longer recommended, and stable addresses 
> are recommended to be generated on based on RFC7217.
> 
> https://tools.ietf.org/html/rfc8064 
> https://tools.ietf.org/html/rfc7217 
> 
> Now it will take a while for new code to completely permeate the industry, 
> but I believe the latest updated for Windows, MAC OS, iOS, and Android, all 
> use this new standard.  I have anecdotal evidence, by playing with my iPhone 
> that was just upgraded to iOS11 that it support this standard.  I don't 
> remember if this was a feature added iOS 10.X or not.
> 
> I believe it is safe to say the majority of new devices no longer use an IID 
> based on a MAC address.  Other than the MAC address of the interface is one 
> of the seeds into the pseudo-random algorithm.
> 
> Thanks
> 
> On Tue, Sep 19, 2017 at 12:17 PM, Owen DeLong  > wrote:
> 
>> On Sep 19, 2017, at 1:28 PM, Leif Sawyer > > wrote:
>> 
>> The majority of devices no longer register on SLAAC with MAC-bound addresses.
> 
> Technically, this isn’t true.
> 
> The majority of devices now register both one or more privacy addresses _AND_ 
> a MAC-bound address. The MAC-bound address on such devices is not used as a 
> preferred or primary address for originating sessions, but can be used (if 
> known by the remote device) as a stable address to connect to services 
> provided by the host.
>  
>> Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, which 
>> is codified in RFC 4941
>> means randomly generated addresses on a rotating basis.
>>  
>> You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's 
>> really not.
> 
> I think the better consideration is that when we talk of allocation and/or 
> assignment, we are talking of the allocation/assignment of network numbers 
> end not of host-portions to end devices. As such, I don’t think that the 
> blurring Albert perceives as being created by SLAAC truly exists regardless 
> of whether it is static or not.
> 
> Owen
> 
>>  
>> Leif
>>  
>>  
>> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net 
>> ] On Behalf Of hostmas...@uneedus.com 
>> 
>> Sent: Tuesday, September 19, 2017 3:25 AM
>> To: arin-ppml@arin.net 
>> Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 
>> Registration Requirements
>>  
>> [External Email] 
>> 
>> Placing ISP/LIR in place of ISP might be the best way to avoid confusion. 
>> As has been pointed out, they are really one and the same.
>> 
>> Otherwise, I think that everything else about the draft is good and 
>> support.
>> 
>> One thing to consider for future discussion is that because of the nature 
>> of IPv6, and its end-to-end nature, and assignment of public addresses, 
>> that the difference between allocate and assign using IPv6 on a specific 
>> /64 segment used for public wifi or otherwise is becoming more fluid.
>> 
>> With SLAAC, an address is formed in part using a MAC address, which 
>> according to the rules for MAC addresses is supposed to be unique. It 
>> could be argued that these addresses are in effect "static", which could 
>> be argued is an assignment of part of the host network's /64, in effect a 
>> static /128 of that network. Due to the rules of SLAAC this happens 
>> without involvement of the host network, other than router advertisements, 
>> since the MAC originates from the guest device, as a different device will 
>> have a different MAC address.
>> 
>> The requirement of at least a /64 in the proposed 6.5.5.4 is good in that 
>> end user networks that have SLAAC cannot be required to register the /128 
>> associated with someones MAC address on their request. Since this limit 
>> is in the proposal, I think we do not need to address the fact that end 
>> user networks running IPv6 and SLAAC in effect are assigning addresses to 
>> end user devices, even though they are not supposed to do this unless the 
>> addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has 
>> a time limit, one could argue that SLAAC addresses are static.
>> 
>> Something to think about.
>> 
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>> 
>> On Mon, 18 Sep 2017, Owen DeLong wrote:
>> 
>> > I refer you to section 6.5.1…
>> >
>> > 6.5.1. Terminology
>> >
>> > The terms ISP and LIR are used interchangeably in this document and any 
>> > use of either term shall be construed to include both meanings.
>> > The term nibble boundary shall mean a 

Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

[David Farmer]

I don't know if its a majority of devices yet, but with RFC8064 the use of
IIDs based on MAC addresses are no longer recommended, and stable addresses
are recommended to be generated on based on RFC7217.

https://tools.ietf.org/html/rfc8064
https://tools.ietf.org/html/rfc7217

Now it will take a while for new code to completely permeate the industry,
but I believe the latest updated for Windows, MAC OS, iOS, and Android, all
use this new standard.  I have anecdotal evidence, by playing with my
iPhone that was just upgraded to iOS11 that it support this standard.  I
don't remember if this was a feature added iOS 10.X or not.

I believe it is safe to say the majority of new devices no longer use an
IID based on a MAC address.  Other than the MAC address of the interface is
one of the seeds into the pseudo-random algorithm.

Thanks

On Tue, Sep 19, 2017 at 12:17 PM, Owen DeLong  wrote:

>
> On Sep 19, 2017, at 1:28 PM, Leif Sawyer  wrote:
>
> The majority of devices no longer register on SLAAC with MAC-bound
> addresses.
>
>
> Technically, this isn’t true.
>
> The majority of devices now register both one or more privacy addresses
> _AND_ a MAC-bound address. The MAC-bound address on such devices is not
> used as a preferred or primary address for originating sessions, but can be
> used (if known by the remote device) as a stable address to connect to
> services provided by the host.
>
>
> Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, which
> is codified in RFC 4941
> means randomly generated addresses on a rotating basis.
>
> You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's
> really not.
>
>
> I think the better consideration is that when we talk of allocation and/or
> assignment, we are talking of the allocation/assignment of network numbers
> end not of host-portions to end devices. As such, I don’t think that the
> blurring Albert perceives as being created by SLAAC truly exists regardless
> of whether it is static or not.
>
> Owen
>
>
> Leif
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net
> ] *On Behalf Of *hostmas...@uneedus.com
> *Sent:* Tuesday, September 19, 2017 3:25 AM
> *To:* arin-ppml@arin.net
> *Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved
> IPv6 Registration Requirements
>
> [External Email]
>
> Placing ISP/LIR in place of ISP might be the best way to avoid confusion.
> As has been pointed out, they are really one and the same.
>
> Otherwise, I think that everything else about the draft is good and
> support.
>
> One thing to consider for future discussion is that because of the nature
> of IPv6, and its end-to-end nature, and assignment of public addresses,
> that the difference between allocate and assign using IPv6 on a specific
> /64 segment used for public wifi or otherwise is becoming more fluid.
>
> With SLAAC, an address is formed in part using a MAC address, which
> according to the rules for MAC addresses is supposed to be unique. It
> could be argued that these addresses are in effect "static", which could
> be argued is an assignment of part of the host network's /64, in effect a
> static /128 of that network. Due to the rules of SLAAC this happens
> without involvement of the host network, other than router advertisements,
>
> since the MAC originates from the guest device, as a different device will
>
> have a different MAC address.
>
> The requirement of at least a /64 in the proposed 6.5.5.4 is good in that
> end user networks that have SLAAC cannot be required to register the /128
> associated with someones MAC address on their request. Since this limit
> is in the proposal, I think we do not need to address the fact that end
> user networks running IPv6 and SLAAC in effect are assigning addresses to
> end user devices, even though they are not supposed to do this unless the
> addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has
> a time limit, one could argue that SLAAC addresses are static.
>
> Something to think about.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Mon, 18 Sep 2017, Owen DeLong wrote:
>
> > I refer you to section 6.5.1…
> >
> > 6.5.1. Terminology
> >
> > The terms ISP and LIR are used interchangeably in this document and any
> use of either term shall be construed to include both meanings.
> > The term nibble boundary shall mean a network mask which aligns on a
> 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4,
> allowing unit quantities of X such that 2^n=X where n is evenly divisible
> by 4, such as 16, 256, 4096, etc.)
> >
> > While it is a little unusual to have definitions outside of section 2,
> these were placed here in section 6.5.1 in order to avoid potential
> conflicts with certain language that was in section 4 at the time of
> writing.
> >
> > Owen
> >
> >> On Sep 18, 2017, at 1:14 PM, John Santos  wrote:
> >>
> >>

Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network

[Brian Jones]

On Tue, Sep 19, 2017 at 1:20 PM Owen DeLong  wrote:

> I’d like to point out that I just learned of a community network that
> claims they did take advantage
> of the existing policy recently, so there is apparently at least one use
> of the present policy.
>
> I support this draft as an improvement to the existing policy, but I
> believe the argument that the
> community networks policy is never used no longer applies.
>

+1
As wireless becomes more prevalent in communities and small towns there may
be an increase in the number of community networks who wish to use this
part of the policy.


> Owen
>
> On Sep 19, 2017, at 12:29 PM, Chris Woodfield  wrote:
>
> I support this, with the comment that the phrase “volunteers play a large
> role” will be open to interpretation. Is this intentional? I’m fine if that
> is the case, but if not, I’d advocate for a more precise definition.
>
> I also support this policy with the stipulation Chris makes here. It needs
to be open to interpretation or flexible enough to allow for communities to
request the needed resources without too much hassle while meeting the
desirable documentation of resources needs of the ARIN community.

--
Brian



> Thanks,
>
> -C
>
> On Sep 19, 2017, at 8:21 AM, Andrew Dul  wrote:
>
> Hello all,
>
> We will be discussing this draft proposal at the upcoming ARIN meeting
> in San Jose.  If you have comments on the updated draft posted below,
> we'd certainly like to hear from you so we can help shape the
> conversation in person.
>
> We have seen some support for this updated draft, but not a lot.
> Furthermore, have we addressed all of your concerns which you might have
> noted earlier on the 1st version of the policy text.
>
> Thanks,
> Andrew
>
> On 8/24/2017 8:22 AM, ARIN wrote:
>
>
>
> Draft Policy ARIN-2017-8: Amend the Definition of Community Network
>
> Problem Statement:
>
> The Community Networks section of the NRPM has not been used since
> implementation in January 2010. Proposal ARIN-2016-7, to increase the
> number of use cases, was abandoned by the Advisory Council due to lack
> of feedback. Proposal ARIN 2017-2, to remove all mention of community
> networks from NRPM was met with opposition by the community. Many
> responded that the definition of “community network” was too narrow,
> which could be the reason for lack of uptake.
>
> Policy statement:
>
> CURRENT NRPM TEXT:
>
> “2.11. Community Network
>
> A community network is any network organized and operated by a
> volunteer group operating as or under the fiscal support of a
> nonprofit organization or university for the purpose of providing free
> or low-cost connectivity to the residents of their local service area.
> To be treated as a community network under ARIN policy, the applicant
> must certify to ARIN that the community network staff is 100%
> volunteers.”
>
> NEW NRPM TEXT:
>
> “2.11 Community Network
>
> A community network is a network organized and operated by a volunteer
> group, not-for-profit, non-profit, charitable organization, or
> educational institution for the purpose of providing free or low-cost
> connectivity, or other Information Technology services to persons or
> entities within their community. Critical functions may be handled by
> paid staff, but volunteers play a large role in offering services
> available through community networks.”
>
> Comments:
>
> Timetable for implementation: Immediate
> _
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
>
>
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network

[Owen DeLong]

I’d like to point out that I just learned of a community network that claims 
they did take advantage
of the existing policy recently, so there is apparently at least one use of the 
present policy.

I support this draft as an improvement to the existing policy, but I believe 
the argument that the
community networks policy is never used no longer applies.

Owen

> On Sep 19, 2017, at 12:29 PM, Chris Woodfield  wrote:
> 
> I support this, with the comment that the phrase “volunteers play a large 
> role” will be open to interpretation. Is this intentional? I’m fine if that 
> is the case, but if not, I’d advocate for a more precise definition.
> 
> Thanks,
> 
> -C
> 
>> On Sep 19, 2017, at 8:21 AM, Andrew Dul > > wrote:
>> 
>> Hello all,
>> 
>> We will be discussing this draft proposal at the upcoming ARIN meeting
>> in San Jose.  If you have comments on the updated draft posted below,
>> we'd certainly like to hear from you so we can help shape the
>> conversation in person. 
>> 
>> We have seen some support for this updated draft, but not a lot. 
>> Furthermore, have we addressed all of your concerns which you might have
>> noted earlier on the 1st version of the policy text.
>> 
>> Thanks,
>> Andrew
>> 
>> On 8/24/2017 8:22 AM, ARIN wrote:
>>> 
>>> 
>>> Draft Policy ARIN-2017-8: Amend the Definition of Community Network
>>> 
>>> Problem Statement:
>>> 
>>> The Community Networks section of the NRPM has not been used since
>>> implementation in January 2010. Proposal ARIN-2016-7, to increase the
>>> number of use cases, was abandoned by the Advisory Council due to lack
>>> of feedback. Proposal ARIN 2017-2, to remove all mention of community
>>> networks from NRPM was met with opposition by the community. Many
>>> responded that the definition of “community network” was too narrow,
>>> which could be the reason for lack of uptake.
>>> 
>>> Policy statement:
>>> 
>>> CURRENT NRPM TEXT:
>>> 
>>> “2.11. Community Network
>>> 
>>> A community network is any network organized and operated by a
>>> volunteer group operating as or under the fiscal support of a
>>> nonprofit organization or university for the purpose of providing free
>>> or low-cost connectivity to the residents of their local service area.
>>> To be treated as a community network under ARIN policy, the applicant
>>> must certify to ARIN that the community network staff is 100%
>>> volunteers.”
>>> 
>>> NEW NRPM TEXT:
>>> 
>>> “2.11 Community Network
>>> 
>>> A community network is a network organized and operated by a volunteer
>>> group, not-for-profit, non-profit, charitable organization, or
>>> educational institution for the purpose of providing free or low-cost
>>> connectivity, or other Information Technology services to persons or
>>> entities within their community. Critical functions may be handled by
>>> paid staff, but volunteers play a large role in offering services
>>> available through community networks.”
>>> 
>>> Comments:
>>> 
>>> Timetable for implementation: Immediate
>>> _
>> 
>> ___
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net 
>> ).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml 
>> 
>> Please contact i...@arin.net  if you experience any 
>> issues.
> 
> ___
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@arin.net if you experience any issues.

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

[Owen DeLong]

> On Sep 19, 2017, at 1:28 PM, Leif Sawyer  wrote:
> 
> The majority of devices no longer register on SLAAC with MAC-bound addresses.

Technically, this isn’t true.

The majority of devices now register both one or more privacy addresses _AND_ a 
MAC-bound address. The MAC-bound address on such devices is not used as a 
preferred or primary address for originating sessions, but can be used (if 
known by the remote device) as a stable address to connect to services provided 
by the host.
 
> Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, which is 
> codified in RFC 4941
> means randomly generated addresses on a rotating basis.
>  
> You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's 
> really not.

I think the better consideration is that when we talk of allocation and/or 
assignment, we are talking of the allocation/assignment of network numbers end 
not of host-portions to end devices. As such, I don’t think that the blurring 
Albert perceives as being created by SLAAC truly exists regardless of whether 
it is static or not.

Owen

>  
> Leif
>  
>  
> From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net 
> ] On Behalf Of hostmas...@uneedus.com 
> 
> Sent: Tuesday, September 19, 2017 3:25 AM
> To: arin-ppml@arin.net 
> Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 
> Registration Requirements
>  
> [External Email] 
> 
> Placing ISP/LIR in place of ISP might be the best way to avoid confusion. 
> As has been pointed out, they are really one and the same.
> 
> Otherwise, I think that everything else about the draft is good and 
> support.
> 
> One thing to consider for future discussion is that because of the nature 
> of IPv6, and its end-to-end nature, and assignment of public addresses, 
> that the difference between allocate and assign using IPv6 on a specific 
> /64 segment used for public wifi or otherwise is becoming more fluid.
> 
> With SLAAC, an address is formed in part using a MAC address, which 
> according to the rules for MAC addresses is supposed to be unique. It 
> could be argued that these addresses are in effect "static", which could 
> be argued is an assignment of part of the host network's /64, in effect a 
> static /128 of that network. Due to the rules of SLAAC this happens 
> without involvement of the host network, other than router advertisements, 
> since the MAC originates from the guest device, as a different device will 
> have a different MAC address.
> 
> The requirement of at least a /64 in the proposed 6.5.5.4 is good in that 
> end user networks that have SLAAC cannot be required to register the /128 
> associated with someones MAC address on their request. Since this limit 
> is in the proposal, I think we do not need to address the fact that end 
> user networks running IPv6 and SLAAC in effect are assigning addresses to 
> end user devices, even though they are not supposed to do this unless the 
> addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has 
> a time limit, one could argue that SLAAC addresses are static.
> 
> Something to think about.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> On Mon, 18 Sep 2017, Owen DeLong wrote:
> 
> > I refer you to section 6.5.1…
> >
> > 6.5.1. Terminology
> >
> > The terms ISP and LIR are used interchangeably in this document and any use 
> > of either term shall be construed to include both meanings.
> > The term nibble boundary shall mean a network mask which aligns on a 4-bit 
> > boundary (in slash notation, /n, where n is evenly divisible by 4, allowing 
> > unit quantities of X such that 2^n=X where n is evenly divisible by 4, such 
> > as 16, 256, 4096, etc.)
> >
> > While it is a little unusual to have definitions outside of section 2, 
> > these were placed here in section 6.5.1 in order to avoid potential 
> > conflicts with certain language that was in section 4 at the time of 
> > writing.
> >
> > Owen
> >
> >> On Sep 18, 2017, at 1:14 PM, John Santos  >> > wrote:
> >>
> >>
> >>
> >> On 9/18/2017 10:37 AM, ARIN wrote:
> >>> The following has been revised:
> >>>
> >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements
> >> [snip]
> >>
> >>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the 
> >>> NRPM, to read: "If the downstream recipient of a static assignment of /64 
> >>> or more addresses requests publishing of that assignment in ARIN's 
> >>> registration database, the ISP should register that assignment as 
> >>> described in section 6.5.5.1."
> >>
> >> I have been under the impression that a common goal of most people 
> >> proposing NRPM changes is to eliminate the use of the term "ISP", since it 
> >> is not defined in the policy and most or all the relevant sections also 
> >> apply to other organizations 

Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network

[Andrew Dul]

Hello all,

We will be discussing this draft proposal at the upcoming ARIN meeting
in San Jose.  If you have comments on the updated draft posted below,
we'd certainly like to hear from you so we can help shape the
conversation in person. 

We have seen some support for this updated draft, but not a lot. 
Furthermore, have we addressed all of your concerns which you might have
noted earlier on the 1st version of the policy text.

Thanks,
Andrew

On 8/24/2017 8:22 AM, ARIN wrote:
>
>
> Draft Policy ARIN-2017-8: Amend the Definition of Community Network
>
> Problem Statement:
>
> The Community Networks section of the NRPM has not been used since
> implementation in January 2010. Proposal ARIN-2016-7, to increase the
> number of use cases, was abandoned by the Advisory Council due to lack
> of feedback. Proposal ARIN 2017-2, to remove all mention of community
> networks from NRPM was met with opposition by the community. Many
> responded that the definition of “community network” was too narrow,
> which could be the reason for lack of uptake.
>
> Policy statement:
>
> CURRENT NRPM TEXT:
>
> “2.11. Community Network
>
> A community network is any network organized and operated by a
> volunteer group operating as or under the fiscal support of a
> nonprofit organization or university for the purpose of providing free
> or low-cost connectivity to the residents of their local service area.
> To be treated as a community network under ARIN policy, the applicant
> must certify to ARIN that the community network staff is 100%
> volunteers.”
>
> NEW NRPM TEXT:
>
> “2.11 Community Network
>
> A community network is a network organized and operated by a volunteer
> group, not-for-profit, non-profit, charitable organization, or
> educational institution for the purpose of providing free or low-cost
> connectivity, or other Information Technology services to persons or
> entities within their community. Critical functions may be handled by
> paid staff, but volunteers play a large role in offering services
> available through community networks.”
>
> Comments:
>
> Timetable for implementation: Immediate
> _

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.

Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

[hostmaster]

Placing ISP/LIR in place of ISP might be the best way to avoid confusion. 
As has been pointed out, they are really one and the same.


Otherwise, I think that everything else about the draft is good and 
support.


One thing to consider for future discussion is that because of the nature 
of IPv6, and its end-to-end nature, and assignment of public addresses, 
that the difference between allocate and assign using IPv6 on a specific 
/64 segment used for public wifi or otherwise is becoming more fluid.


With SLAAC, an address is formed in part using a MAC address, which 
according to the rules for MAC addresses is supposed to be unique.  It 
could be argued that these addresses are in effect "static", which could 
be argued is an assignment of part of the host network's /64, in effect a 
static /128 of that network.  Due to the rules of SLAAC this happens 
without involvement of the host network, other than router advertisements, 
since the MAC originates from the guest device, as a different device will 
have a different MAC address.


The requirement of at least a /64 in the proposed 6.5.5.4 is good in that 
end user networks that have SLAAC cannot be required to register the /128 
associated with someones MAC address on their request.  Since this limit 
is in the proposal, I think we do not need to address the fact that end 
user networks running IPv6 and SLAAC in effect are assigning addresses to 
end user devices, even though they are not supposed to do this unless the 
addresses were allocated to them like an ISP/LIR.  Unlike DHCP6, which has 
a time limit, one could argue that SLAAC addresses are static.


Something to think about.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Mon, 18 Sep 2017, Owen DeLong wrote:


I refer you to section 6.5.1???

6.5.1. Terminology

The terms ISP and LIR are used interchangeably in this document and any use of 
either term shall be construed to include both meanings.
The term nibble boundary shall mean a network mask which aligns on a 4-bit 
boundary (in slash notation, /n, where n is evenly divisible by 4, allowing 
unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 
16, 256, 4096, etc.)

While it is a little unusual to have definitions outside of section 2, these 
were placed here in section 6.5.1 in order to avoid potential conflicts with 
certain language that was in section 4 at the time of writing.

Owen


On Sep 18, 2017, at 1:14 PM, John Santos  wrote:



On 9/18/2017 10:37 AM, ARIN wrote:

The following has been revised:

* Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements

[snip]


4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: 
"If the downstream recipient of a static assignment of /64 or more addresses requests 
publishing of that assignment in ARIN's registration database, the ISP should register that 
assignment as described in section 6.5.5.1."


I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the 
use of the term "ISP", since it is not defined in the policy and most or all the relevant sections 
also apply to other organizations that, while they re-allocate or reassign address space, are not, properly 
speaking, ISPs.  Shouldn't this says "LIR" or "provider" or some other more generic term?


[snip]

--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.


___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.