アカウント名:
パスワード:
NATなどを用いれば、確かに/29程度のaddress blockでも(networkの構造という意味での)エンドユーザは十分なのかも知れません。しかし、各ユーザからの回線を集線するISPなどはかえって大変なことになりそうです。
address blockを増やすと、経路表もそれに応じて長くなります。ということは、packet forwardの際に経路表を引く時間が長くなる可能性があります。これを防ぐため、従来はaddress blockをaggregateして経路表を最小限に抑えていたとか。ですが、最近では上からもらえるblockはまず間違いなくぶつ切りになってしまうそうです。また、networkの至るところでblockが必要になってしまう状況(全国各地でユーザ数が増えていく場合など)になると、穴埋め的に小さなblockをあちこちでばらまくハメになることもあるでしょう。結果としてaggregateできないblockがnetwork全体に流れてしまう [wide.ad.jp]ことになります。大手のISPになるとospfでは経路制御が追いつかなくなる [wide.ad.jp]恐れすらあります。
何年か前にUSAGIのcoreの一人から聞いたのですが、IPv6の本当の目玉はaggregateしやすいaddress block割り当てを実現し、経路制御を楽にするということだとか。したがって、addressに対してnetwork識別部とhost識別部を厳格に区別すること、prefix長の選択に余裕を持たせることなどが絶対要求になったそうです。個々のaddressが不足するかどうかという問題はほとんど気にしていませんでした(こっちが問題の本質だったら迷わず可変長addressを使っていたでしょうねぇ...)。
というわけで、エンドユーザにとって十分足りているように見えるIPv4 addressも、routerを守る人にとってはとっくの昔に使い果たしてしまったものというのが実情でしょうか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
ぶつ切りaddress block問題 (スコア:3, 参考になる)
NATなどを用いれば、確かに/29程度のaddress blockでも(networkの構造という意味での)エンドユーザは十分なのかも知れません。しかし、各ユーザからの回線を集線するISPなどはかえって大変なことになりそうです。
address blockを増やすと、経路表もそれに応じて長くなります。ということは、packet forwardの際に経路表を引く時間が長くなる可能性があります。これを防ぐため、従来はaddress blockをaggregateして経路表を最小限に抑えていたとか。ですが、最近では上からもらえるblockはまず間違いなくぶつ切りになってしまうそうです。また、networkの至るところでblockが必要になってしまう状況(全国各地でユーザ数が増えていく場合など)になると、穴埋め的に小さなblockをあちこちでばらまくハメになることもあるでしょう。結果としてaggregateできないblockがnetwork全体に流れてしまう [wide.ad.jp]ことになります。大手のISPになるとospfでは経路制御が追いつかなくなる [wide.ad.jp]恐れすらあります。
何年か前にUSAGIのcoreの一人から聞いたのですが、IPv6の本当の目玉はaggregateしやすいaddress block割り当てを実現し、経路制御を楽にするということだとか。したがって、addressに対してnetwork識別部とhost識別部を厳格に区別すること、prefix長の選択に余裕を持たせることなどが絶対要求になったそうです。個々のaddressが不足するかどうかという問題はほとんど気にしていませんでした(こっちが問題の本質だったら迷わず可変長addressを使っていたでしょうねぇ...)。
というわけで、エンドユーザにとって十分足りているように見えるIPv4 addressも、routerを守る人にとってはとっくの昔に使い果たしてしまったものというのが実情でしょうか。
Re:ぶつ切りaddress block問題 (スコア:1)
でもそれって、ハードがどんどん克服していってないかい？イマドキ、そういうでかい経路をもつルータは全部ハード処理してるから、
> packet forwardの際に経路表を引く時間が長くなる可能性が
> あります。
ってのは過去の話だと思われます。これが問題になる場面っていうのは、「経路をひく時間が長くなる」という場面ではなくて、「運用者がどのエリアに割り当てたアドレスかをぱっと見てわからない。」という部分にあると思います。アドレスの集約って、最近ではルータの負荷とかじゃなくて、運用者が見やすいかどうかでやってることですからね。
そういう意味では IPv6 の価値はあると思われます。
ただ、IPv6 が入ってくると、それをワイヤスピードで処理できルータがでてこないと意味がないわけで、現在の帯域の伸びに IPv6 のルーティング処理能力がついていってるかはハナハダ疑問なわけで。
--- show mpls ldp neighbor
Re:ぶつ切りaddress block問題 (スコア:0)
>> packet forwardの際に経路表を引く時間が長くなる可能性が
>> あります。
> ってのは過去の話だと思われます。
とはならないのではないでしょうか。経路表を引く時間が一定になる
チップが一般的につかわれているのでしょうか？
Re:ぶつ切りaddress block問題 (スコア:0)
Re:ぶつ切りaddress block問題 (スコア:0)
もうあるでしょ。青い箱とか。
日本産の黒い箱もハードウェア処理するモジュールが出ているし。
> 現在の帯域の伸びに IPv6 のルーティング
Re:ぶつ切りaddress block問題 (スコア:1)
バックボーンに接続するルーターは、帯域より先にこの制限でリプレース強要されることもあるらしい。
Re:ぶつ切りaddress block問題 (スコア:0)
Re:ぶつ切りaddress block問題 (スコア:0)
Re:ぶつ切りaddress block問題 (スコア:1)
Re:ぶつ切りaddress block問題 (スコア:0)
出来ないという事はありません。
IPv4と全く同等のクオリティで提供できるかは、実際に運用した
ことないので知りませんが
Re:ぶつ切りaddress block問題 (スコア:0)