From: rick.jones2@hp.com   
      
   BGB / cr88192  wrote:   
      
   > this way, ones' task would be in steps:   
      
   > alternate packet format which can handle larger addresses, but   
   > which: handles old addresses transparently; is still routable via   
   > stupid hardware   
      
   Stupid hardware would be able to deal with the destination network   
   address now being 32 bits farther into the header than it was before?   
   (Or did I miss something or should have read-on futher to the below?)   
      
   > one option for this could have been to create a special IP protocol tag,   
   > which would have contained an "IP extension header", which could have   
   > contained:   
   > the added middle 32-bits for the to/from addresses;   
   > possibly either a new "protocol" or "next header" field, ...   
      
   The new parts would then have to be proper subsets of the old parts   
   no?  Anything in the middle of your new 192.168.0.0.0.0.0.1 would have   
   to be in the same routing path as 192.168.0.1 for it to be handled by   
   older equipment right?  Wouldn't that only serve to give more   
   addresses to those who already have them rather than spread addresses   
   out among more recipients?   
      
   > (thus the new format would have been a hacked form of the old   
   > format...).   
      
   > granted, this is far from perfect, but could have likely been   
   > deployed more rapidly.   
      
   I suspect the router types (who, near as I can tell/recall were very   
   influential in IPv6) would have gone ape over that.   
      
   rick jones   
   --   
   firebug n, the idiot who tosses a lit cigarette out his car window   
   these opinions are mine, all mine; HP might not want them anyway... :)   
   feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)