Re: IPv4 address length technical design

[Johnny Eriksson]

valdis.kletni...@vt.edu wrote:

> And the -10s and -20s were the major reason RFCs refer to octets
> rather than bytes, as they had a rather slippery notion of "byte"
> (anywhere from 6 to 9 bits, often multiple sizes used *in the
> same program*).

Not quite correct.  Anywhere from 1 to 36 bits, and not spanning
a 36-bit word boundary.  Essentialy what is now known as a bit field.

--Johnny

Re: IPv4 address length technical design

[Masataka Ohta]

Eugen Leitl wrote:

> Except that these will be pure photonic networks, and apart from optical
> delay lines for your packet buffer you'd better be able to make a routing
> (switching) decision

Seriously speaking, that is the likely future as 1T
Ethernet will be impractical.

The point is to use 1Tbps packet by encoding a packet
simultaneously over, for example, 100 wavelengths each
encoded at 10Gbps.

> while few bits of the header have streamed by your
> photonic router circuit.
> 
> There is no time for any table look-ups, obviously.

At 1Tbps, 500B packet is 4ns long, which is long enough
for full /24 (with limited support for /32) look up.

While wavelengths containing header information are used
for table look up and rewritten, rest of the wavelengths
are delayed.

What you can't use with fiber delay lines is hash table,
which means large number (beyond CAM capacity) of Ethernet
MAC addresses is unusable and IPv6 with current allocation
scheme is bad.

> And optical gates are *really* expensive, so better use few of
> them. And don't add too many gate delays, too.

That's one reason why we should use 1Tbps packets. A gate
should switch not 10Gbps but 1Tbps or faster data.

Another reason is that 1Tbps packet needs 100 times shorter
delay lines to buffer than 10Gbps ones.

> Above describes your setting for the next protocol. There is not
> a lot of leeway in design space, I'm afraid.

Just keep using IPv4.

Masataka Ohta
PS

See ftp://chacha.hpcl.titech.ac.jp/IEEE-ST.ppt presented
at a summer topical of IEEE photonic society.

Re: IPv4 address length technical design

[Marco Hogewoning]

On Oct 4, 2012, at 12:21 AM, Owen DeLong wrote:

> IEEE 802 was expected to provide unique numbers for all computers ever built.
> 
> Internet was expected to provide unique numbers for all computers actively on 
> the network.
> 
> Obviously, over time, the latter would be a declining percentage of the 
> former since the former is increasing and never decrements while the latter 
> could (theoretically) have a growth rate on either side of zero and certainly 
> has some decrements even if the increments exceed the decrements.

Which brings the question, are we expected to ever run out of the 48 bits for 
mac-addresses? Of course there are exceptions, but in most cases you can 
probably start recycling them after a certain period. And that period could 
even become shorter over time, I mean what are the chances you find a iPhone 1 
in your network these days?

Marco

Re: [tt] IPv4 address length technical design

[Eugen Leitl]

On Thu, Oct 04, 2012 at 05:10:00PM +0900, Masataka Ohta wrote:

> > Above describes your setting for the next protocol. There is not
> > a lot of leeway in design space, I'm afraid.
> 
> Just keep using IPv4.
> 
>   Masataka Ohta
> PS
> 
> See ftp://chacha.hpcl.titech.ac.jp/IEEE-ST.ppt presented
> at a summer topical of IEEE photonic society.

Thanks for the Powerpoint, I've already seen it or an
earlier version of it.

My (minor) beef with it is that while you offload most of
heavy lifting to photonics you still use electronics and
lookup. It is however reasonably easy to do everything
at effectively L2 with a photonic crossbar if you encode
geography in the headers (you have a direct proximity
metric on your link slots).

(You can actually prototype this with Ethernet MACs,
as 2^48 in square meters happens to be half the surface 
area of the Earth http://www.wolframalpha.com/input/?i=2^48+m^2
So MAC collisions are not very probable, if distributed
optimally ;)

If you do it in optics the protocol is completely different
from IPv4/IPv6, so you would encapsulate and use it as
a transport layer for legacy (ha!) protocols.

P.S. Sorry for shit-stirring (and it ain't even Friday yet).
 I'll be good now.

Re: [tt] IPv4 address length technical design

[Masataka Ohta]

Eugen Leitl wrote:

> My (minor) beef with it is that while you offload most of
> heavy lifting to photonics you still use electronics and
> lookup.

Because for non linear operations, electronics is a lot
better than so linear photonics w.r.t. speed, power,
size etc.

And, it's not my idea. See 'The "Staggering Switch": An
Electronically Controlled Optical Packet Switch' by
Zygmunt Haas, which mentioned "almost all optical" in
1993.

> It is however reasonably easy to do everything
> at effectively L2 with a photonic crossbar if you encode
> geography in the headers (you have a direct proximity
> metric on your link slots).

How can you say BGP, then?

> (You can actually prototype this with Ethernet MACs,
> as 2^48 in square meters happens to be half the surface
> area of the Earth http://www.wolframalpha.com/input/?i=2^48+m^2
> So MAC collisions are not very probable, if distributed
> optimally ;)

The problem with large number (beyond size of CAM with reasonable
power consumption) of MAC is that hash table is necessary,
which means route look up time is not bounded, which means
fiber delay lines can not be used.

Thousands of MAC addresses in a small L2 WAN is fine, except
that BGP does not work.

> If you do it in optics the protocol is completely different
> from IPv4/IPv6,

What I have shown is that what will be completely different will
be L2.

IPv4 uber alles.

Masataka Ohta

Dropping IPv6 Fragments

[Tom Taylor]

Who drops IPv6 fragments in their network, under what circumstances?

Tom Taylor

Re: Dropping IPv6 Fragments

[Saku Ytti]

On (2012-10-04 10:16 -0400), Tom Taylor wrote:

> Who drops IPv6 fragments in their network, under what circumstances?

No one who offers working IP connections.

Dropping IPv6 fragments against your control-plane, that is another
discussion, but dropping them in transit would be short-lived exercise.

-- 
  ++ytti

Re: Dropping IPv6 Fragments

[Tom Taylor]

On 04/10/2012 10:20 AM, Saku Ytti wrote:

On (2012-10-04 10:16 -0400), Tom Taylor wrote:


Who drops IPv6 fragments in their network, under what circumstances?


No one who offers working IP connections.

Dropping IPv6 fragments against your control-plane, that is another
discussion, but dropping them in transit would be short-lived exercise.

Let's talk control plane, then. Under what circumstances do fragments 
get dropped?

Re: Dropping IPv6 Fragments

[Sander Steffann]

Hi,

>> Who drops IPv6 fragments in their network, under what circumstances?
> 
> No one who offers working IP connections.
> 
> Dropping IPv6 fragments against your control-plane, that is another
> discussion, but dropping them in transit would be short-lived exercise.

Depends on where you are looking. In the core network dropping fragments is not 
that common AFAIK. The closer you get to the edge the more common it might 
become...

- Sander

Re: Dropping IPv6 Fragments

[Dobbins, Roland]

On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:

> The closer you get to the edge the more common it might become...

iACLs should be implemented at the network edge to drop all IPv4 and IPv6 
traffic - including non-initial fragments - directed towards point-to-point 
links, loopbacks, and other internal infrastructure with exceptions made for 
cases where there's a legitimate need for sources outside your network to be 
able to communicate with your infrastructure.

As mentioned previously on the thread, this has nothing to do with transit 
data-plane traffic, which should be left untouched unless it's specifically 
classified as attack traffic or other undesirable traffic.

There's an apparently common misperception that fragmented traffic is somehow 
bad.  It isn't.  It's normal, under most circumstances.  Protect your 
infrastructure proactively, deal with anything else on a case-by-case basis.

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: Dropping IPv6 Fragments

[joel jaeggli]

On 10/4/12 7:36 AM, Dobbins, Roland wrote:

On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:


The closer you get to the edge the more common it might become...

iACLs should be implemented at the network edge to drop all IPv4 and IPv6 
traffic - including non-initial fragments - directed towards point-to-point 
links, loopbacks, and other internal infrastructure with exceptions made for 
cases where there's a legitimate need for sources outside your network to be 
able to communicate with your infrastructure.

As mentioned previously on the thread, this has nothing to do with transit 
data-plane traffic, which should be left untouched unless it's specifically 
classified as attack traffic or other undesirable traffic.

There's an apparently common misperception that fragmented traffic is somehow 
bad.  It isn't.  It's normal, under most circumstances.  Protect your 
infrastructure proactively, deal with anything else on a case-by-case basis.


So the thing I'd note is that stateless IPV6 ACLs or load balancing 
provide you with an interesting problem since a fragment does not 
contain the headers beyond the required unfragmentable headers. it is 
possible but unlikely that the fragment  will hash into the same bucket 
in a stateless load balancer (using what's left of 5-tuple).


Likewise with the acl I have the property that the initial packet has 
all the info in it while the fragment does not. I would have to 
reassemble the packet  (which isn't going to happen in the place where 
the stateless acl is applied) prior to being able to decide to pass it 
or not (or just pass fragments through that acl).

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: IPv4 address length technical design

[joel jaeggli]

On 10/4/12 1:31 AM, Marco Hogewoning wrote:

On Oct 4, 2012, at 12:21 AM, Owen DeLong wrote:


IEEE 802 was expected to provide unique numbers for all computers ever built.

Internet was expected to provide unique numbers for all computers actively on 
the network.

Obviously, over time, the latter would be a declining percentage of the former 
since the former is increasing and never decrements while the latter could 
(theoretically) have a growth rate on either side of zero and certainly has 
some decrements even if the increments exceed the decrements.

Which brings the question, are we expected to ever run out of the 48 bits for 
mac-addresses? Of course there are exceptions, but in most cases you can 
probably start recycling them after a certain period. And that period could 
even become shorter over time, I mean what are the chances you find a iPhone 1 
in your network these days?


The IEEE/RAC regards the consistent enforcement of these restrictions as a
fundamental and realistic basis for ensuring longevity of the EUI-48 
identifier
capability, with a target lifetime of 100 years for existing 
applications using EUI-48

identifiers.

http://standards.ieee.org/develop/regauth/tut/eui.pdf


Marco

Re: Dropping IPv6 Fragments

[Dobbins, Roland]

On Oct 4, 2012, at 9:58 PM, joel jaeggli wrote:

> Likewise with the acl I have the property that the initial packet has 
> all the info in it while the fragment does not. 

For iACLs, just filter non-initial fragments directed to infrastructure IPs.  
Cisco & Juniper ACLs have ACL matching criteria for non-initial fragments.

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Technical contact at XO/Concentric

[Knut A. Syed]

Hi,

If anyone from XO/Concentric is on on the list or anyone has a technical 
contact who can help with connectivity issues to their hosted Web-sites, 
please pass this along to the right person/team or respond to me off-list.


Some of our customers are having problems connecting to Web-services 
hosted by XO/Concentric. The problem is limited to customers within a 
certain /17 allocation we have (82.134.0.0/17). Ping and connections to 
the SMTP-service on the same destination IP are fine.  But when the 
customers try to connect to the HTTP-service tcpdumps shows that no 
packets are returned.


We have tried Customer Care to no help.

TIA!

Kind Regards,

Knut A. Syed

Re: Dropping IPv6 Fragments

[joel jaeggli]

On 10/4/12 8:15 AM, Dobbins, Roland wrote:

On Oct 4, 2012, at 9:58 PM, joel jaeggli wrote:


Likewise with the acl I have the property that the initial packet has
all the info in it while the fragment does not.

For iACLs, just filter non-initial fragments directed to infrastructure IPs.  Cisco 
& Juniper ACLs have ACL matching criteria for non-initial fragments.


Yeah, that's more or less what we said in RFC 6192.

That said as the network operator of a content provider I have more 
devices in my portfolio than just backbone routers.


---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton

Re: IPv4 address length technical design

[Bjorn Leffler]

On Wed, Oct 3, 2012 at 12:13 PM, Chris Campbell  wrote:
>
> Is anyone aware of any historical documentation relating to the choice of 32 
> bits for an IPv4 address?

I've heard Vint Cerf say this himself, but here's a written reference
for you. They had just finished building arpanet, which was expensive
to build. Hence why they estimated two networks per country.

http://www.domainpulse.com/2012/06/06/world-ipv6-day/

When developing IPv4, Cerf said that he and Bob Kahn “estimated that
there might be two national-scale packet networks per country and
perhaps 128 countries able to build them, so 8 bits sufficed for 256
network identifiers. Twenty-four bits allowed for up to 16 million
hosts. At that time, hosts were big, expensive time-sharing systems,
so 16 million seemed like a lot. We did consider variable length and
128-bit addressing in 1977 but decided that this would be too much
overhead for the relatively low-speed lines (50 kilobits per second).
I thought this was still an experiment and that if it worked we would
then design a production version.

100.100.0.0/24

[joel jaeggli]

http://bgp.he.net/net/100.100.0.0/24#_bogon

A surprising number of large transit ASes appear to be more than willing 
to accept this prefix from AS4847.


I'd be a lot happier if there were fewer.

thanks
joel

Re: Dropping IPv6 Fragments

[Merike Kaeo]

On Oct 4, 2012, at 7:36 AM, Dobbins, Roland wrote:

> 
> On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:
> 
>> The closer you get to the edge the more common it might become...
> 
> iACLs should be implemented at the network edge to drop all IPv4 and IPv6 
> traffic - including non-initial fragments - directed towards point-to-point 
> links, loopbacks, and other internal infrastructure with exceptions made for 
> cases where there's a legitimate need for sources outside your network to be 
> able to communicate with your infrastructure.
> 
> As mentioned previously on the thread, this has nothing to do with transit 
> data-plane traffic, which should be left untouched unless it's specifically 
> classified as attack traffic or other undesirable traffic.

+1

> There's an apparently common misperception that fragmented traffic is somehow 
> bad.  It isn't.  It's normal, under most circumstances.  Protect your 
> infrastructure proactively, deal with anything else on a case-by-case basis.

Same misconception as ICMP is badhistorical artifact from attacks in early 
90's that just perpetuate in mythical best practice.

I was just investigating with varying folks whether they also log v6 fragment 
filtering exceptions and whether anyone has seen anything 'interesting' :)  
Nothing interesting yet. 

I'm co-authoring a doc in IETF which consolidates v6 security practices and 
looks to provide info for what current BCP is as folks are more actively 
deploying v6.  Was just at RIPE to get input from that operator community and 
want to solicit input here as well.  

Doc is at: http://tools.ietf.org/html/draft-ietf-opsec-v6-00

Feedback on mailing list would be great: 
https://www.ietf.org/mailman/listinfo/opsec   but, if easier to send email to 
authors just do so directly and we'll incorporate and vet appropriately.  All 3 
authors follow quite a few *NOG lists and have been involved in deployments so 
hopefully this can help educate the less informed.

- merike
 
> 
> ---
> Roland Dobbins  // 
> 
> Luck is the residue of opportunity and design.
> 
>  -- John Milton
> 
> 

Re: 100.100.0.0/24

[Scott Weeks]

--- joe...@bogus.com wrote:
From: joel jaeggli 

http://bgp.he.net/net/100.100.0.0/24#_bogon

A surprising number of large transit ASes appear to be more than willing 
to accept this prefix from AS4847.

I'd be a lot happier if there were fewer.
-



To save others the time of looking it up... :-)

http://tools.ietf.org/html/rfc6598

scott

Re: IPv4 address length technical design

[Tony Finch]

Owen DeLong  wrote:
>
> Once host identifiers are no longer dependent on or related to topology,
> there's no reason a reasonable fixed-length cannot suffice.

Host identities should be cryptographic hashes of public keys, so you have
to support algorithm agility, which probably implies variable length.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

Re: IPv4 address length technical design

[Valdis . Kletnieks]

On Thu, 04 Oct 2012 09:57:34, Johnny Eriksson said:
> valdis.kletni...@vt.edu wrote:
>
> > And the -10s and -20s were the major reason RFCs refer to octets
> > rather than bytes, as they had a rather slippery notion of "byte"
> > (anywhere from 6 to 9 bits, often multiple sizes used *in the
> > same program*).
>
> Not quite correct.  Anywhere from 1 to 36 bits, and not spanning
> a 36-bit word boundary.  Essentialy what is now known as a bit field.

Right - but in actual programming practice, code tended to distinguish
between a "byte" and "N bit wide field of flags or whatever".  And bytes
as character storage ran from 6 to 9 bits depending on the charset in use.


pgpAu3riImDRv.pgp
Description: PGP signature

Re: 100.100.0.0/24

[Christopher Morrow]

On Thu, Oct 4, 2012 at 1:17 PM, joel jaeggli  wrote:
> http://bgp.he.net/net/100.100.0.0/24#_bogon
>
> A surprising number of large transit ASes appear to be more than willing to
> accept this prefix from AS4847.

that took longer than expected.
the internet has failed my expectations.

Re: Dropping IPv6 Fragments

[Fernando Gont]

Hi, Joel,

On 10/04/2012 10:58 AM, joel jaeggli wrote:
> So the thing I'd note is that stateless IPV6 ACLs or load balancing
> provide you with an interesting problem since a fragment does not
> contain the headers beyond the required unfragmentable headers.

In the real world, such packets are not legitimate, so feel free to drop
them. draft-ietf-6man-oversized-header-chain formally addresses this issue.


> Likewise with the acl I have the property that the initial packet has
> all the info in it while the fragment does not.

You're talking about initial-fragment vs non-initial fragments? -- If
so, in theory *both* might be missing the upper layer information. IN
practice, the first-fragment won't. If it does, feel free to drop it.

Cheers,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

TOR Question

[Joseph Lappa]

Hi,

   There was a thread on Nanog in January about TOR and deep buffers
(http://seclists.org/nanog/2012/Jan/966).   I have a follow-up,
related question.

   Has anyone used a TOR switch to aggregate connections to from major
network providers?  For example,  2 or more 10GE ingress connections
(pick your favorite CDNs) into one 10GE egress back to our router
(which is at a remote location).   We are worried that queue buffers
are too small to handle the traffic going to the egress port.

Thanks,
Joe Lappa

Re: IPv4 address length technical design

[Owen DeLong]

On Oct 4, 2012, at 11:19 AM, Tony Finch  wrote:

> Owen DeLong  wrote:
>> 
>> Once host identifiers are no longer dependent on or related to topology,
>> there's no reason a reasonable fixed-length cannot suffice.
> 
> Host identities should be cryptographic hashes of public keys, so you have
> to support algorithm agility, which probably implies variable length.
> 

No, they really shouldn't, but I understand why some security zealots think 
that's a good idea.

Owen

Re: IPv4 address length technical design

[William Herrin]

On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R
 wrote:
> On Oct 3, 2012, at 6:49 PM, Jimmy Hess  wrote:
>> In 100 years, when we start to run out of IPv6 addresses,  possibly we
>> will have learned our lesson and done  two things:
>>
>>  (1)   Stopped  mixing the Host identification and the Network
>> identification into the same bit field;   instead  every packet gets a
>> source network address,  destination network address, AND  an
>> additional  tuple of   Source host address,   destination host
>> address;  residing in completely separate address spaces,  with  no
>> "Netmasks",  "Prefix lengths", or other comingling of  network
>> addresses and host address spaces.
>>
>> And
>>  (2)  The new protocol will use  variable-length address for the Host
>> portion, such as  used in the addresses of CLNP,  with a convention of
>> a specified length,  instead of a hardwired specific limit  that comes
>> from using a permanently  fixed-width field.
>
> I suggest that the DNS name space should be considered to be
> an "hierarchical host address space" thus satisfying (1) and making (2) moot.

I'd suggest that too, but we'd have to throw out TCP, UDP and a good
chunk of the BSD sockets API to get there.

Or did you mean use DNS as it fits in the current system, which
doesn't actually satisfy (1) at all since the layer 4 protocols
continue to build the connection identity from the layer 3 network
identity instead of the external host/service identity.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: IPv4 address length technical design

[Cutler James R]

On Oct 4, 2012, at 4:00 PM, William Herrin  wrote:
> On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R
>  wrote:
>> On Oct 3, 2012, at 6:49 PM, Jimmy Hess  wrote:
>>> In 100 years, when we start to run out of IPv6 addresses,  possibly we
>>> will have learned our lesson and done  two things:
>>> 
>>> (1)   Stopped  mixing the Host identification and the Network
>>> identification into the same bit field;   instead  every packet gets a
>>> source network address,  destination network address, AND  an
>>> additional  tuple of   Source host address,   destination host
>>> address;  residing in completely separate address spaces,  with  no
>>> "Netmasks",  "Prefix lengths", or other comingling of  network
>>> addresses and host address spaces.
>>> 
>>> And
>>> (2)  The new protocol will use  variable-length address for the Host
>>> portion, such as  used in the addresses of CLNP,  with a convention of
>>> a specified length,  instead of a hardwired specific limit  that comes
>>> from using a permanently  fixed-width field.
>> 
>> I suggest that the DNS name space should be considered to be
>> an "hierarchical host address space" thus satisfying (1) and making (2) moot.
> 
> I'd suggest that too, but we'd have to throw out TCP, UDP and a good
> chunk of the BSD sockets API to get there.
> 
> Or did you mean use DNS as it fits in the current system, which
> doesn't actually satisfy (1) at all since the layer 4 protocols
> continue to build the connection identity from the layer 3 network
> identity instead of the external host/service identity.
> 
> Regards,
> Bill Herrin

Yes. 

Why does the connection identity have to include the host identifier.  Is that 
not a problem under the control of applications?

Re: IPv4 address length technical design

[William Herrin]

On Thu, Oct 4, 2012 at 4:17 PM, Cutler James R
 wrote:
> On Oct 4, 2012, at 4:00 PM, William Herrin  wrote:
>> On Wed, Oct 3, 2012 at 7:12 PM, Cutler James R
>>  wrote:
>> Or did you mean use DNS as it fits in the current system, which
>> doesn't actually satisfy (1) at all since the layer 4 protocols
>> continue to build the connection identity from the layer 3 network
>> identity instead of the external host/service identity.
>>
> Why does the connection identity have to include the host identifier.  Is 
> that not a problem under the control of applications?

Nope. It's under the control of the layer 4 protocol, generally TCP or
UDP, and implemented at the OS level. For example, in TCP the
connection identity is composed of the source and destination IP
addresses and port numbers. Together, these 96 bits of information
comprise the unique identity of that TCP connection which the OS
matches to the socket number the application interacts with.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Dropping IPv6 Fragments

[Mark Andrews]

In message , Merik
e Kaeo writes:
> 
> On Oct 4, 2012, at 7:36 AM, Dobbins, Roland wrote:
> 
> >=20
> > On Oct 4, 2012, at 9:26 PM, Sander Steffann wrote:
> >=20
> >> The closer you get to the edge the more common it might become...
> >=20
> > iACLs should be implemented at the network edge to drop all IPv4 and =
> IPv6 traffic - including non-initial fragments - directed towards =
> point-to-point links, loopbacks, and other internal infrastructure with =
> exceptions made for cases where there's a legitimate need for sources =
> outside your network to be able to communicate with your infrastructure.
> >=20
> > As mentioned previously on the thread, this has nothing to do with =
> transit data-plane traffic, which should be left untouched unless it's =
> specifically classified as attack traffic or other undesirable traffic.
> 
> +1
> 
> > There's an apparently common misperception that fragmented traffic is =
> somehow bad.  It isn't.  It's normal, under most circumstances.  Protect =
> your infrastructure proactively, deal with anything else on a =
> case-by-case basis.
> 
> Same misconception as ICMP is badhistorical artifact from attacks in =
> early 90's that just perpetuate in mythical best practice.   =20

And it really hurts modern DNS where UDP responses often exceed
Ethernet MTU.  For IPv6 UDP DNS responses are often fragmented at
1280 to prevent PMTUD being needed.  For IPv4 PMTUD should be off
if your vendor followed the RFC's (know exception are Linux and
Solaris boxes).

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Dropping IPv6 Fragments

[Masataka Ohta]

Fernando Gont wrote:

> In the real world, such packets are not legitimate, so feel free to drop
> them. draft-ietf-6man-oversized-header-chain formally addresses this issue.

The ID misses the problem of 4->6 translator.

That is, though the ID state:

   Entire IPv6 header chain:
  All protocol headers starting from the fixed IPv6 header till (and
  including) the upper layer protocol header (TCP, UDP, etc. --
  assuming there is one of those),

the translator may not have any knowledge on how long "the upper
layer protocol header" is. Thus, the requirement of the ID is
impossible to enforce.

Moreover, a 68B IPv4 fragment of some packet with 60B upper layer
protocol header can not be translated to IPv6.

In theory, with 60B IPv4 header, a 68B IPv4 fragment can't even
contain an entire TCP header.

So, the requirement of the ID should be to require only the first
8B of the upper layer protocol header.

All the (pseudo) transport protocols working over IPv4 is
designed to identify transport identity with the first 8B
of transport headers.

>> Likewise with the acl I have the property that the initial packet has
>> all the info in it while the fragment does not.
> 
> You're talking about initial-fragment vs non-initial fragments? -- If
> so, in theory *both* might be missing the upper layer information.

Yes, that is one of an annoying point of IPv6.

Masataka Ohta

Re: IPv4 address length technical design

[Barry Shein]

In Singapore in June 2011 I gave a talk at HackerSpaceSG about just
doing away with IP addresses entirely, and DNS.

Why not just use host names directly as addresses? Bits is bits, FQDNs
are integers because, um, bits is bits. They're even structured so you
can route on the network portion etc.

Routers themselves could hash them into some more efficient form for
table management but that wouldn't be externally visible. I did
suggest a standard for such hashing just to help with debugging etc
but it'd only be a suggestion or perhaps common display format.

About the only obvious objection, other than vague handwaves about
compute efficiency, is it would potentially make packets a lot longer
in the worst case scenario, longer than common MTUs tho not much
longer unless we also allow a lengthening of host name max, 1024 right
now I believe? So 2K max for src/dest and whatever other overhead
payload you need, not unthinkable.

OTOH, it just does away with DNS entirely which is some sort of
savings.

There are obviously some more details required, this email is not a
replacement for a set of RFCs!

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: IPv4 address length technical design

[Mark Andrews]

In message <20590.7539.491575.455...@world.std.com>, Barry Shein writes:
> 
> In Singapore in June 2011 I gave a talk at HackerSpaceSG about just
> doing away with IP addresses entirely, and DNS.
> 
> Why not just use host names directly as addresses? Bits is bits, FQDNs
> are integers because, um, bits is bits. They're even structured so you
> can route on the network portion etc.

It's the worst idea I've heard in a long time.  Names have nothing
to do with physical location or how you reach a machine.

> Routers themselves could hash them into some more efficient form for
> table management but that wouldn't be externally visible. I did
> suggest a standard for such hashing just to help with debugging etc
> but it'd only be a suggestion or perhaps common display format.
> 
> About the only obvious objection, other than vague handwaves about
> compute efficiency, is it would potentially make packets a lot longer
> in the worst case scenario, longer than common MTUs tho not much
> longer unless we also allow a lengthening of host name max, 1024 right
> now I believe? So 2K max for src/dest and whatever other overhead
> payload you need, not unthinkable.
> 
> OTOH, it just does away with DNS entirely which is some sort of
> savings.
> 
> There are obviously some more details required, this email is not a
> replacement for a set of RFCs!
> 
> -- 
> -Barry Shein
> 
> The World  | b...@theworld.com   | http://www.TheWorld.com
> Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
> Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv4 address length technical design

[George Herbert]

On Thu, Oct 4, 2012 at 4:36 PM, Barry Shein  wrote:
>
> In Singapore in June 2011 I gave a talk at HackerSpaceSG about just
> doing away with IP addresses entirely, and DNS.
>
> Why not just use host names directly as addresses? Bits is bits, FQDNs
> are integers because, um, bits is bits. They're even structured so you
> can route on the network portion etc.
>
> Routers themselves could hash them into some more efficient form for
> table management but that wouldn't be externally visible. I did
> suggest a standard for such hashing just to help with debugging etc
> but it'd only be a suggestion or perhaps common display format.
>
> About the only obvious objection, other than vague handwaves about
> compute efficiency, is it would potentially make packets a lot longer
> in the worst case scenario, longer than common MTUs tho not much
> longer unless we also allow a lengthening of host name max, 1024 right
> now I believe? So 2K max for src/dest and whatever other overhead
> payload you need, not unthinkable.
>
> OTOH, it just does away with DNS entirely which is some sort of
> savings.
>
> There are obviously some more details required, this email is not a
> replacement for a set of RFCs!

You'd still need DNS for non-A/PTR types of records.

This scheme fails miserably in one practical manner - it's impossible
to tell people far away from the source of a DNS / name domain's
authority that a.foo.com and b.foo.com are in the UK and c.foo.com and
d.foo.com are in Japan.  With IP addresses, heirarchical blocks make
routing trivial.  Name based routing is ... seems hard, or insanely
hard for "real complex networks" as opposed to trivial end user types
of situations.  Possibly unworkably hard.

One could rename things such as having a.location.foo.com but you
still encounter the problem that you have to propogate knowledge of
where location.foo.com is further out into the universe.

Nice troll and/or wild-crazy-idea though.


-- 
-george william herbert
george.herb...@gmail.com

Re: 100.100.0.0/24

[Anurag Bhatia]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Friday 05 October 2012 12:04 AM, Christopher Morrow wrote:
> On Thu, Oct 4, 2012 at 1:17 PM, joel jaeggli  wrote:
>> http://bgp.he.net/net/100.100.0.0/24#_bogon
>>
>> A surprising number of large transit ASes appear to be more than
willing to
>> accept this prefix from AS4847.
>
> that took longer than expected.
> the internet has failed my expectations.
>
I learnt to use whois for such strange results! :)


anurag@laptop:~$ whois 100.64.0.0
#
# The following results may also be obtained via:
#
http://whois.arin.net/rest/nets;q=100.64.0.0?showDetails=true&showARIN=false&ext=netref2
#

NetRange:   100.64.0.0 - 100.127.255.255
CIDR:   100.64.0.0/10
OriginAS:
NetName:SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:  NET-100-64-0-0-1
Parent: NET-100-0-0-0-0
NetType:IANA Special Use
Comment:This block is used as Shared Address Space. Traffic from
these addresses does not come from IANA. IANA has simply reserved these
numbers in its database and does not use or operate them. We are not the
source of activity you may see on logs or in e-mail records. Please
refer to http://www.iana.org/abuse/
Comment: 
Comment:Shared Address Space can only be used in Service
Provider networks or on routing equipment that is able to do address
translation across router interfaces when addresses are identical on two
different interfaces.
Comment: 
Comment:This block was assigned by the IETF in the Best Current
Practice document,
Comment:RFC 6598 which can be found at:
Comment:http://tools.ietf.org/html/rfc6598
RegDate:2012-03-13
Updated:2012-04-23
Ref:http://whois.arin.net/rest/net/NET-100-64-0-0-1




- -- 
Anurag Bhatia
http://anuragbhatia.com
Twitter: @anurag_bhatia
Skype: anuragbhatia.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJQbiVaAAoJEPnIYygGLJNaV18H/Rg/TJiMhh6QbYHX04JFLQ1V
UOd0ihW128qpKllFMuqmwkeBFF2psPqrSdCBGqk+J1CQtgmcgwPNUaebVzoijaa/
kuPBMJNod6DhIiwKSZlkWkL5cF7buhh+E0neT4LMHsE/qVxgXEYZF/Z0OWR1L71e
38xw8Nx2javtXcBlpPbMDriFekmv4B1tSw9R4aHDJolquYmjZzBpOSj8EAX5hYLW
vj7nc6SYp5lGuwgbSYCwPZvIXN0Olt/puuabeVFRXbwKWml/wScAunBIbCoP/n2G
gT1MdVpcMnsBj1ZJC/fIy70Wlu/6d7z4hq8OMosLXZ3ayrmCU0QAslr6GUOhYz0=
=RUOc
-END PGP SIGNATURE-

Re: IPv4 address length technical design

[Jay Ashworth]

- Original Message -
> From: "Barry Shein" 

> In Singapore in June 2011 I gave a talk at HackerSpaceSG about just
> doing away with IP addresses entirely, and DNS.
> 
> Why not just use host names directly as addresses? Bits is bits, FQDNs
> are integers because, um, bits is bits. They're even structured so you
> can route on the network portion etc.
> 
> Routers themselves could hash them into some more efficient form for
> table management but that wouldn't be externally visible. I did
> suggest a standard for such hashing just to help with debugging etc
> but it'd only be a suggestion or perhaps common display format.

And Whacky Weekend begins early.

Jim?  Jim Fleming?  How'd you break into Barry's email account?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274