I have been using v6 since 2007, and everything that was ever stated in
the RFCs and in practice always recommended that assignments align on a
nibble boundary. Having had many v4 assignments less than /24, I know of
the CNAME tricks used. I never had a non nibble aligned v6 assignment, as
I always received a /48.
Having never used anything outside of a nibble boundary, I never actually
considered v6 NS records outside of a nibble boundary are much easier than
the v4 CNAME trick. It appears that no more than 8 NS records would be
required for any chosen boundary.
Based on comments so far, most agree that a /48 should be SWIP'ed since it
is routable on the internet, and since so far the majority seems to think
that /56 is small enough to not require SWIP, this leaves 7 choices of /49
to /55 to set the limit for SWIP in the Draft.
I still think a nibble boundary aligned value of "more than /52" or "more
than a /56" will be the best choices in that range to place in the draft,
rather than a non nibble aligned value.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Thu, 15 Jun 2017, Owen DeLong wrote:
On May 25, 2017, at 21:02 , hostmas...@uneedus.com wrote:
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 subdividing the rDNS for more than one customer in a /24 of v4.
Actually, this isn???t true.
It just means _EXTRA_ NS entries.
For example, 2001:db8:beef::/48 can be delegated as
f.e.e.b.8.b.d.0.1.0.0.2.ip6.arpa. as a single NS record set.
However, to delegate 2001:db8:beef:e000::/49, one needs two NS delegations:
e.f.e.e.b.8.b.d.0.1.0.0.2.ip6.arpa.
and f.f.e.e.b.8.d.b.0.1.0.0.2.ip6.arpa.
No CNAME requirement at all.
CNAME tricks would only come into play if delegating reverse for prefixes
longer than /124. (Just as in IPv4, they only come into play longer than /24).
Owen
_______________________________________________
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.
