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 problems with waste when we use say 5000 addreseses on a /64, but not with using 2 in a point to point link, forgetting that the difference between 5000 and 2 is nothing when there is 18 million trillion addresses on that subnet.

It was also pointed out that using a /127 prevented certain attacks, but simply turning off neighbor discovery (the true issue) on these links also has the same effect. Maybe someone should update that RFC. I think the advantages of /64 everywhere I think outweighs the value of using a /127 p2p link.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Thu, 25 May 2017, Aaron Dudek wrote:

I don't believe a /64 is recommended for a p2p anymore. Rfc 6164

On Thursday, May 25, 2017, Jason Schiller <jschil...@google.com> wrote:

I don't support a relaxation of SWIP requirements for IPv4.

I do support updating the language for IPv4 for clarity (if that is
useful).
current IPv4 language:  /29 or more

possibly re-write for clarity: more than a /30.


As far as IPv6 goes, there are some who recommend a /64 for point-to-point.
One might argue that in the context of p-t-p an IPv4 /30 maps to a /64.

I could certainly get behind SWIP requirements for "more than a /64" on
these grounds.

Please make the requirement to SWIP be on a nibble boundary.


Nibbles being nice things, one could argue that end users are likely to
get a /64
or the next size up which is a /60.  If you want to catch all customers in
the
smallest size, you might make the boundary at "more than a /61"

The next size up on the nibble boundary is a /56 putting the boundary at
"more than a /57"


Generally speaking any network that is sufficiently large to require
subnetting,
should have sufficient clue to support SWIP.  Based on this reasoning
"more than
a /64" seems like an equable place to draw the line.  Even "more than a
/61"
seems reasonable, as blocks are likely going to be assigned on nibbles.
My next preferred choice would be "more than a /57"

Also don't forget that residential users can opt out of publicly providing
information.

___Jason







On Tue, May 23, 2017 at 10:04 PM, <hostmas...@uneedus.com
<javascript:_e(%7B%7D,'cvml','hostmas...@uneedus.com');>> wrote:

Hello,

The line has to be drawn somewhere, and the idea when I drafted this
proposal was that it was wrong to treat IPv6 less favored than IPv6 as is
the current case.  It also bothered me that the average residential and
small business account would have to go thru the SWIP process, just because
they want to have a minimum or so assignment of IPv6 space for their
network, when this was never a requirement for IPv4.  As discussed, a /60
of v6 is much the same as a /32 of v4.

I chose 16 addresses/networks as the only reasonable number to make the
two protocols equal. As already discussed, 1 network is too small.  If the
community thinks it is wrong to relax the current IPv4 requirements, I am
not opposed to removing 4.2.3.7.1 from the proposal, as long as the
community is willing to do something about the "Register every network"
problem that is the current policy in v6, and the changes to 6.5.5.1 that I
propose.

While I suggest that a /60 should not trigger registration, if the
community would rather kick that up to a /56, I have no problem with this.
This would seem to be the more future proof option. Of course such a change
calls for a new title, maybe "New policy for IPv6 Assignment Registration",
and cite it as allowing even the small networks with a /32 of IPv4 to
obtain a reasonable assignment of IPv6 without registration requirements,
as is the current case with IPv4.

Albert Erdmann
Network Administrator
Paradise On Line Inc.



On Tue, 23 May 2017, William Herrin wrote:

On Tue, May 23, 2017 at 2:35 PM, ARIN <i...@arin.net
<javascript:_e(%7B%7D,'cvml','i...@arin.net');>> wrote:

Draft Policy ARIN-2017-5: Equalization of Assignment Registration
requirements between IPv4 and IPv6

Policy statement:

Amend 4.2.3.7.1 of the policy manual to strike "/29 or more" and change
to
"more than a /28".


Hello,

In my opinion...

Leave /29 alone or change it to "more than a single IP address." In these
days of IPv4 shortage, substantial networks sit behind small blocks of
public addresses. These networks should be documented with reachable POCs
lest the anti-spam/virus/malware folks slam down /24 filters for lack of
information about how misbehaving networks are partitioned.


Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to
"more than a /60".


Change this to "more than a /56." Service providers should NOT be
assigning
/64's to end users. If you're doing that, you're doing it wrong. An IPv6
customer should be able to have more than one /64 subnet without
resorting
to NAT so /60 should be the absolute minimum end-user assignment,
equivalent for all intents and purposes to an IPv4 /32. If we then want
"equivalence" to the /29 policy so that individuals with the minimum and
near-minimum assignment do not need to be SWIPed, it makes sense to move
the next subnetting level up. In IPv6, assignment is strongly recommended
on nibble boundaries, so that means /56.

Regards,
Bill Herrin

--
William Herrin ................ her...@dirtside.com
<javascript:_e(%7B%7D,'cvml','her...@dirtside.com');>  b...@herrin.us
<javascript:_e(%7B%7D,'cvml','b...@herrin.us');>
Dirtside Systems ......... Web: <http://www.dirtside.com/>

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net
<javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','i...@arin.net');> if you experience any
issues.




--
_______________________________________________________
Jason Schiller|NetOps|jschil...@google.com
<javascript:_e(%7B%7D,'cvml','jschil...@google.com');>|571-266-0006



_______________________________________________
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.

Reply via email to