>From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>
>In message <BB2831D3689AD211B14C00104B14623B1E7569@HAZEN04>, "David A Higginbot
>ham" writes:
>>I agree! Why create a finite anything when an infinite possibility exists?
>>On another note, I have heard the argument that a unique identifier already
>>exists in the form of a MAC address why not make further use of it?
>
>Would it surprise anyone to hear that all of that was considered and
>discussed, ad nauseum, in the IPng directorate? That's right -- we weren't
>stupid or ignorant of technological history. There were proponents for
>several different schemes, including fixed-length addresses of 64 and later
>128 bits, addresses where the two high-order bits denoted the multiple of 64
>to be used (that was my preference), or CLNP, where addresses could be quite
>variable in length (I forget the maximum).
>
>But the first thing to remember is that there are tradeoffs. Yes, infinitely
>long addresses are nice, but they're much harder to store in programs (you can
>no longer use a simple fixed-size structure for any tuple that includes an
>address) and (more importantly) route, since the router has to use the entire
>address in making its decision. Furthermore, if it's a variable-length
>address, the router has to know where the end is, in order to look at the next
>field. (Even if the destination address comes first, routers have to look at
>the source address because of ACLs -- though you don't want address-based
>security (and you shouldn't want it), you still need anti-spoofing filters.)
>I should add, btw, that there's a considerable advantage to having addresses
>be a multiple of the bus width in size, since that simplifies fetching the
>next field.)
>
Routers may use the different addresses for routing. Outbound router
may assign "route address" to keep intermediate route tables small.
It is not the same as NAT because original and real destination address
never replaced.
- Leonid Yegoshin.
