Sorry the late answer been extremely busy for a few days and had big email
backlog.
El 27/3/19 23:12, "[email protected] en nombre de [email protected]"
<[email protected] en nombre de [email protected]> escribió:
On Tue, 26 Mar 2019, JORDI PALET MARTINEZ via ARIN-PPML wrote:
>
> El 26/3/19 23:23, "[email protected] en nombre de
[email protected]" <[email protected] en nombre de
[email protected]> escribiÓ:
>
> I am opposed.
>
> IPv6 policies have been designed from the beginning to limit the growth
of
> the global routing tables. Policies such as sparse assignment help with
> this goal, as well as the development of means to renumber with relative
> ease, compared to IPv4. This is because more than one upstream can be
> advertised at the same time and in the same network. A RFC compliant
host
> will by default assign addresses in each subnet that it hears router
> advertisements and spread its outgoing traffic between the available
> upstream routers. Unlike IPv4, we are nowhere near exhaust, and there
is
>
> Have you really tried that ? Thinks aren't so easy as it may seem.
Yes, I have done this for the last 6 years. It works 100% on inbound
traffic. I agree there is a big issue with MS boxes choosing just a
single outbound IPv6 route and never failing over, except to IPv4 because
of happy eyeballs in the browser.
Working only for inbound traffic is not a solution.
>
> no need to get into the legacy transfer issue with IPv6. I would perfer
> to allow each IPv6 block assigned to a RIR to remain 100% under the
> control of that RIR. If transfers are possible, this fact alone can be
> used to defeat the trust anchor.
>
> It is unclear to me what the trust anchor problem actually is, and why
it
> needs to lead to the explosion of the IPv6 DFZ because of transfers. If
>
> This policy will not increase the DFZ. The same number of routes you
> have in one region will just move to another one, same or different
> upstreams.
>
IPv6 was designed from the beginning to allow more than one router on a
lan. Therefore each router can be associated with a different ISP. Hosts
will assign an address on each network that sends a router advertisement.
Since I am using only the ISP default route on each /64 ISP provided
network, you are correct, the number of routes in the DFZ do not change.
This is also the way you can easily (compared to IPv4) migrate to a new
address block, by marking the old one as depreciated. At that point, old
connections are continued, but all new ones happen on the new address
block.
You mean renumbering. We had a big IETF effort to try that. Is not that easy.
It means somebody need to change, for example, DNS. This means that you can't
have multihoming with automatic failover, load sharing/balancing, etc., not
that easy.
> there is an issue of ARIN policy regarding trust anchors compared to
other
> RIR's, this policy should instead be addressed instead of allowing
> transfers as a work around to a bad ARIN policy.
>
> Ideally, IPv6 blocks should be obtained from the upstream ISP/LIR and
they
> should be routed to the default route, with only one route per ISP/LIR.
>
> Ideally yes, one router per ISP/LIR, but not all follow that because
> "traffic engineering".
True, but usually all customers in a given area use that same set of
routes, and this does not require any route involvement at the ISP.
>
> If I understand correctly, you're saying that we must not have IPv6 PI?
>
No, I am not saying that at all. I am pointing out that in IPv6 that
multihome and failover should work over standard ISP connections, without
any involvement with the upstream ISP. This also allows failover without
having to obtain IPv6 PI space, using only the upstream provided IPv6
addresses. If you have a site that needs more bandwidth than a standard
connection can provide, you can choose to use two or more different
providers to provide the required bandwidth and also obtain failover
without any additional costs. Each host will obtain an IPv6 address from
every available router. In the case of MS windows, it will only use one of
the provided IPv6 /64's for outbound connections, but which one is chosen
is quite random and tends to be close to evenly split between each of them
in a group of MS windows machines. I wish that MS would read the RFCs and
split their outbound bandwidth use between all available connections like
Linux does.
> Since the "normal" site assignment is a /48, unlike IPv4, there is no
> shortage of address space for any use without involvement of ARIN or
other
> RIR. If one needs to be multihomed, each host can have an address from
> each available upstream, providing availability to each host from more
> than one network.
>
> Have you tried that? Hosts don't multihome today with IPv6 with multiple
> prefixes from different upstreams. You really need IPv6 PI.
>
I have, and have been doing it for the last 6 years. It does require DNS
tricks. I have a script running that removes the AAAA record for any
upstream that is not available, and replaces it when it returns. Of course
that record uses a TTL of 60. It simply pings each circuit's gateway
address to determine the up/down status of that connection once a minute,
and adds/removes the DNS records for the IP address for that connection
assigned to each host on the network that has either failed or returned.
While not instant or perfect, the script is cheap and requires no
additional hardware or costs.
Not instant means is not usable. If it means having a low TTL is bad for being
able to cache the RR, etc.
I can't agree this is the way at all.
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Tue, 26 Mar 2019, ARIN wrote:
>
> > On 21 March 2019, the ARIN Advisory Council (AC) accepted
"ARIN-prop-263:
> > Allow Inter-regional IPv6 Resource Transfers" as a Draft Policy.
> >
> > The Draft Policy text is below and can be found at:
> > https://www.arin.net/participate/policy/drafts/2019_4/
> >
> > You are encouraged to discuss all Draft Policies on PPML. The AC will
> > evaluate the discussion in order to assess the conformance of this
draft
> > policy with ARIN's Principles of Internet number resource policy as
stated in
> > the Policy Development Process (PDP). Specifically, these principles
are:
> >
> > * Enabling Fair and Impartial Number Resource Administration
> > * Technically Sound
> > * Supported by the Community
> >
> > The PDP can be found at:
> > https://www.arin.net/participate/policy/pdp/
> >
> > Draft Policies and Proposals under discussion can be found at:
> > https://www.arin.net/participate/policy/drafts/
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers
> >
> > Problem Statement:
> >
> > There is an operational need to allow RIR transfers of IPv6 resources
between
> > RIRs with an equivalent transfer policy. ARINâ•˙s RPKI Trust Anchor
(TA) is
> > measurably less widely deployed than TAs from other RIRs. As a
consequence,
> > RPKI ROAs published through ARIN offer less value. Operators seeking
to
> > extract the most value from their investment in IPv6 would benefit
from the
> > ability to transfer IPv6 resources to RIRs with more widely deployed
RPKI
> > Trust Anchors.
> >
> > Policy Statement:
> >
> > Change the first sentence in section 8.4 from:
> >
> > ╲Inter-regional transfers of IPv4 number resources and ASNs may
take place
> > only via RIRs who agree to the transfer and share reciprocal,
compatible
> > needs-based policies.╡
> >
> > To:
> >
> > ╲Inter-regional transfers of Internet number resources may take
place only
> > via RIRs who agree to the transfer and share reciprocal, compatible
> > needs-based policies.╡
> >
> > Comments:
> >
> > Timetable for implementation: Immediate
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List ([email protected]).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact [email protected] if you experience any issues.
> >_______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of the
individual(s) named above and further non-explicilty authorized disclosure,
copying, distribution or use of the contents of this information, even if
partially, including attached files, is strictly prohibited and will be considered
a criminal offense. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this information, even
if partially, including attached files, is strictly prohibited, will be considered
a criminal offense, so you must reply to the original sender to inform about this
communication and delete it.
>
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
>_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of the
individual(s) named above and further non-explicilty authorized disclosure,
copying, distribution or use of the contents of this information, even if
partially, including attached files, is strictly prohibited and will be
considered a criminal offense. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited, will be considered a criminal offense, so you must reply to the
original sender to inform about this communication and delete it.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
