Mailing List Archive

The interNIC has already stated that allocations can *not* be guaranteed
to be 'routable', so it stands to reason that the interNIC (or any other
registry, for that matter) need not concern itself with the issue of
portability. As you mentioned, this is strictly a matter between the ISP(s)
and the customer(s).

- paul


At 05:35 PM 6/3/96 -0700, Bill Manning wrote:

> Please clarify "portable" as used in this context.
>
> - Routable between different providers
> - Transferable intoto between ISPs
> - Transferable subsets
> - Some other meaning
>
> No delegation registry can claim any prefix portability if
> the first option is the meaning. The second has applicability
> to various proposals for a prefix market once a delegation
> has been made. (no Internic involvment) The third is strictly
> between ISPs and thier clients and has a lot to do with
> prefix migration (nee punching holes in CIDR blocks) and nothing
> to do with the Internic. And then there is your possible
> other meaning...
>
> For the first three, the Internic has zero sane reason for
> issuing any "edict" wrt portability. That is strictly an
> ISP issue. The fourth... ??? :)
>
>
>--bill
>

- - - - - - - - - - - - - - - - -

>
> The interNIC has already stated that allocations can *not* be guaranteed
> to be 'routable', so it stands to reason that the interNIC (or any other
> registry, for that matter) need not concern itself with the issue of
> portability. As you mentioned, this is strictly a matter between the ISP(s)
> and the customer(s).
>
> - paul
>
>
> At 05:35 PM 6/3/96 -0700, Bill Manning wrote:
>
> > Please clarify "portable" as used in this context.
> >
> > - Routable between different providers
> > - Transferable intoto between ISPs
> > - Transferable subsets
> > - Some other meaning
> >
> > No delegation registry can claim any prefix portability if
> > the first option is the meaning. The second has applicability
> > to various proposals for a prefix market once a delegation
> > has been made. (no Internic involvment) The third is strictly
> > between ISPs and thier clients and has a lot to do with
> > prefix migration (nee punching holes in CIDR blocks) and nothing
> > to do with the Internic. And then there is your possible
> > other meaning...
> >
> > For the first three, the Internic has zero sane reason for
> > issuing any "edict" wrt portability. That is strictly an
> > ISP issue. The fourth... ??? :)
> >
> >
> >--bill
> >
>

- - - - - - - - - - - - - - - - -

> The interNIC has already stated that allocations can *not* be guaranteed
> to be 'routable', so it stands to reason that the interNIC (or any other
> registry, for that matter) need not concern itself with the issue of
> portability. As you mentioned, this is strictly a matter between the ISP(s)
> and the customer(s).
>
> - paul

I think portable wrt the NICs may be:

(1) The 'Portable' vs. 'Non-Portable' marker on the ISP IP request template

(2) The 'Portable' vs. 'Non-Portable' marker on whois queries that says:

ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE

Now, as to what it *means*, it probably means that if you asked the NIC
in question, they'd say 'touch luck' if you wanted to contest a SWIPping
away from you of the space, I suppose.

Of course, since the NIC refuses to delegate > /16s worth of in-addr.arpa,
unless you have a <= /16 from your provider, you're not going to get useful
in-addr.arpa from your old provider if they don't want you to.

Avi

- - - - - - - - - - - - - - - - -

At 09:48 PM 6/3/96 -0400, Avi Freedman wrote:

>
>I think portable wrt the NICs may be:
>
>(1) The 'Portable' vs. 'Non-Portable' marker on the ISP IP request template
>
>(2) The 'Portable' vs. 'Non-Portable' marker on whois queries that says:
>
> ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
>
>Now, as to what it *means*, it probably means that if you asked the NIC
>in question, they'd say 'touch luck' if you wanted to contest a SWIPping
>away from you of the space, I suppose.
>
>Of course, since the NIC refuses to delegate > /16s worth of in-addr.arpa,
>unless you have a <= /16 from your provider, you're not going to get useful
>in-addr.arpa from your old provider if they don't want you to.
>
>Avi
>

It would appear, then, that a better definition for 'portable' needs to
come in existence. Which is why I particularly liked
draft-ietf-cidrd-addr-ownership-07.txt.

After re-reading draft-hubbard-registry-guidelines-01.txt, its not readily
apparent what 'portability' really means; I'm not so sure that it was the
goal of the authors to define portability.

It does state, however, that:

[snip]

2) Routability: Distribution of globally unique Internet addresses
in a hierarchical manner, permitting the routing scalability of
the addresses. This scalability is necessary to ensure proper
operation of Internet routing, although it must be stressed that
routability is in no way guaranteed with the allocation or
assignment of IPv4 addresses.

[snip]

Hence my earlier comment.

The topic is discussed in more detail in draft-ietf-cidrd-addr-ownership-07.txt:

[snip]

Since the Internet does not constrain its topology (or allowed
topology changes), we can either have address ownership for everyone
or a routable Internet, but not both, or we need to develop and
deploy new mechanisms (e.g., by decoupling the address owned by the
end users from those used by the Internet routing, and provide
mechanisms to translate between the two). In the absence of new
mechanisms, if we have address ownership ("portable" addresses) for
everyone, then the routing overhead will lead to a breakdown of the
routing system resulting in a fragmented (partitioned) Internet.
Alternately, we can have a routable Internet, but without address
ownership ("portable" addresses) for everyone.


[snip]

- paul

- - - - - - - - - - - - - - - - -

Paul,

>
> The topic is discussed in more detail in
> draft-ietf-cidrd-addr-ownership-07.txt:

Interesting that you reference a draft that was opposed by numerous
people, and did not reach 'rough concensus', to support a new draft :-)

It is like building your house on quicksand.... it is sure to sink
into the quick eventually....

As you can see, many of us are engaged in 'contract issues' at the
moment .... viz. (Contract and RA) and are not actively commenting
on this draft.... but, IMO, it requires 'some work' to move
toward an objective engineering document and has obvious bias that
is still not technically supported (emotionally supported, yes).

If you could contain this discussion, for the moment in the PIER-WG
and out of the radar range (i.e. NANOG) for a while it would be
appreciated, I think. But then again, you are certainly free to
do PIER-WG work in NANOG... but why?

Best Regards,

Tim


- - - - - - - - - - - - - - - - -

Tim,

This stemmed from a 'what *is* portable?' discussion. I believe its
relevant in NANOG, regardless of overlap into an IETF WG topic.

In any event (and to open old wounds), I *liked* the addr-ownership
draft and believed it should've been advanced as BCP, but I digress.
Whether or not there was consensus that it should have been adopted
and advanced is not relevant; the topics it discussed surely are.

- paul

At 10:50 PM 6/3/96 -0400, @NANOG-LIST wrote:

>>
>> The topic is discussed in more detail in
>> draft-ietf-cidrd-addr-ownership-07.txt:

[snip]

>If you could contain this discussion, for the moment in the PIER-WG
>and out of the radar range (i.e. NANOG) for a while it would be
>appreciated, I think. But then again, you are certainly free to
>do PIER-WG work in NANOG... but why?
>

- - - - - - - - - - - - - - - - -

>
The InterNIC has not mandated non-portability, they have strongly
encouraged it.

Kim Hubbard
InterNIC Registry

> Hi,
>
> Anyone know whether Internic has issued an edict mandating
> non-portability of provider obtained 206 address space, such
> as /18's within this block?
>
> Thanks,
> Mike
>
> ---------------------------------------
> Mike Levy, PhD, PE (206)217-0158, fax:282-9445
> Cortland Electronics Corp. mike@cortland.com
> 1509 Queen Anne Ave N., Suite 274 http://www.cortland.com
> Seattle, WA 98109
>
>

- - - - - - - - - - - - - - - - -